一起聊一聊emacs27?

是挺尴尬的。

27 发布在即了吧,估计短时间不会有太大提升,等 native 还不如 dynamic module 靠谱。

看大家的测试数据,和目前的体验确实差不多。

太囧了 :rofl: :rofl: :rofl:

这里头是出了什么问题?是Jansson的实现不好吗?还是说Elisp绑定没做好?

我在mac上用MS的word软件编辑doc时,会出现拷贝快捷键Command+C失效的情况,有时候连按两次也失效,所以现在每次拷贝就连按4下!:sob::sob::sob::sob:

When performing benchmark with native parser wrap the call to the native parsing with (with-temp-buffer …) - related discussion - bug#31138: Native json slower than json.el and [discussion] writing json parser as rust module · Issue #4 · ubolonton/emacs-module-rs · GitHub

1 个赞

I will post the results with elp performance testing and with enabled both native parsing + json el to have comparison in the real usecase: (compare lsp--read-json-el and lsp--read-native-json the code available at Use native JSON functionality in Emacs 27 · Issue #210 · emacs-lsp/lsp-mode · GitHub )

lsp--parser-on-message                                 171         4.825922573   0.0282217694
lsp--read-json                                         171         4.601956367   0.0269120255
lsp--read-json-el                                      171         3.9113452219  0.0228733638
lsp--parser-read                                       1307        1.0518447099  0.0008047778
lsp--read-native-json                                  171         0.688050226   0.0040236855
lsp--on-notification                                   130         0.0726324090  0.0005587108
lsp--on-diagnostics                                    7           0.063708947   0.0091012781
lsp-ui-sideline                                        30          0.05643676    0.0018812253
lsp--make-message                                      56          0.0562572890  0.0010045944
lsp-ui-sideline--diagnostics-changed                   7           0.055627562   0.0079467945
lsp--send-request-async                                43          0.0467603880  0.0010874508
lsp-ui-doc--on-hover                                   2           0.029292634   0.014646317
lsp-ui-sideline--run                                   7           0.026202328   0.0037431897
1 个赞

都不想升级到27。。。

The (with-temp-buffer ...) does not make native parsing faster:

⋊> ./src/emacs -Q --batch -l ~/.scratch/emacs/benchmark-native-json.el
(w/benchmark '100000 '(json-parse-string json-string))     ;; => Elapsed time: 25.451464s (16.632284s in 728 GCs)
(w/benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 30.148163s (18.175661s in 866 GCs)

⋊> ./src/emacs -Q --batch -l ~/.scratch/emacs/benchmark-native-json.el
(w/benchmark '100000 '(json-parse-string json-string))     ;; => Elapsed time: 22.577644s (14.639583s in 728 GCs)
(w/benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 38.248179s (22.567974s in 866 GCs)

⋊> ./src/emacs -Q --batch -l ~/.scratch/emacs/benchmark-native-json.el
(w/benchmark '100000 '(json-parse-string json-string))     ;; => Elapsed time: 22.662395s (14.645539s in 728 GCs)
(w/benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 29.729253s (17.643603s in 866 GCs)

⋊> ./src/emacs -Q --batch -l ~/.scratch/emacs/benchmark-native-json.el
(w/benchmark '100000 '(json-parse-string json-string))     ;; => Elapsed time: 22.388149s (14.668245s in 728 GCs)
(w/benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 29.638171s (17.242109s in 866 GCs)

⋊> ./src/emacs -Q --batch -l ~/.scratch/emacs/benchmark-native-json.el
(w/benchmark '100000 '(json-parse-string json-string))     ;; => Elapsed time: 27.819788s (15.239697s in 728 GCs)
(w/benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 30.269438s (18.141456s in 858 GCs)

⋊> ./src/emacs -Q --batch -l ~/.scratch/emacs/benchmark-native-json.el
(w/benchmark '100000 '(json-parse-string json-string))     ;; => Elapsed time: 26.836383s (14.706035s in 728 GCs)
(w/benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 29.445384s (17.515654s in 858 GCs)

I have updated Emacs to the recent version of the master branch.

Here is my test code: benchmark native and json.el #emacs · GitHub

I mentioned in the lsp-mode issue, there is no much effect in small jsons since I believe that the elisp funcall is as slow as the parsing itself.

Here are the results with large.json · GitHub (the first run is without (with-temp-buffer ...)

➜  Desktop ~/.bin/emacs-latest/bin/emacs -Q --batch -l benchmark-native-json.el
GNU Emacs 27.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-03-10
(benchmark 100 '(json-read-from-string json-string))               ;; => Elapsed time: 18.488213s (10.891228s in 1365 GCs)
(benchmark 100 '(json-parse-string json-string))                   ;; => Elapsed time: 8.127364s (1.391082s in 100 GCs)
➜  Desktop ~/.bin/emacs-latest/bin/emacs -Q --batch -l benchmark-native-json.el
GNU Emacs 27.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-03-10
(benchmark 100 '(json-read-from-string json-string))               ;; => Elapsed time: 18.890727s (11.152488s in 1365 GCs)
(benchmark 100 '(json-parse-string json-string))                   ;; => Elapsed time: 5.538966s (1.364898s in 100 GCs)

In my experiencing, lsp-mode has more features than eglot, but it’s slower. Looks like the bottleneck is parsing JSON. What’s the difference of parsing JSON between lsp-mode and eglot? And the doc UI of eglot looks nicer than lsp-mode now although it didn’t.

There was one extremely slow piece of code on the hot path (see lsp--sort-completions in Native json support by yyoncho · Pull Request #691 · emacs-lsp/lsp-mode · GitHub) . In addition to that, the native json will speedup lsp-mode too. After these changes, on my 4 years old PC lsp-mode feels pretty much instant and visually there is no speed difference between lsp-mode and vscode(except maybe dart language server which returns 3.5 mb results). I would point also that the completion filtering should be moved on the client. I think that @tigersoldier is working on that and this will improve the experience a lot.

Can you post screenshots about the doc(or directly a PR)? I must admit I haven’t spent a lot of time working on lsp-ui(although there is a lot of stuff to be done). The priority for now is to cover the lsp spec so we could use that as a base for further improvements.

If you see an area in which lsp-mode is lagging behind any other language server client just go ahead and file a PR.

Vibhab, the author of lsp-mode is also returning which will improve the pace a bit. I am spending ~10 hours a week coding which is not enough to cover all the things that I want to do in the packages that I am interested in (lsp-mode/dap-mode/lsp-ui/lsp-ide/helm-lsp/spacemacs/lsp-ide/lsp-treemacs/lsp-java) but still I believe that lsp-mode has improved a lot since 3-4 months ago. Still given the scope of the project lsp-mode ecosystem needs more contributors/members/maitainers.

6 个赞

Thank you for the update! I am impressive of the improvements of lsp-mode recently. I believe it has bight feature. I am using lsp-mode with pls and bingo all the time, but sometimes try eglot and do some comparisons. The screenshots are below.

  • eglot

  • lsp-mode

FYI eglot uses gfm.el

Yes, seems it’s rendered as markdown buffer.

I recalled it from my memory. I just looked up the source, seems eglot uses gfm-view-mode in markdown.el (instead of gfm.el, which doesn’t exist).

I juede yinggai gai biaoti cheng yiqi liaoliao lsp

1 个赞

哥们儿真逗,我翻译了半天才回过神来 :joy::sweat_smile::sweat:

应该是聊聊原生json

这届写c的不行,强行和elisp五五开是搞毛? :joy:

1 个赞

看截图应该是 rst(非 markdown),python 社区的通用文档格式。

从 Markdown 到 reStructuredText

代码里用的是gfm-view-mode.