一起聊一聊emacs27?


#21

还是觉得有缓存的更好

这样能减轻lsp的工作量

redis还能存储到文件 可以将常用的包的补全、文档什么的保存起来


#22

elpa里有eredis

更多的工作应该是在lsp-server那里


#23

lsp客户端行为不一定一样, 比如company-capf加eglot, 每输入一个字符company-capf都会重新请求补全项目(即使company的补全菜单还有补全项没用完), 卡的简直没法用. 最后改代码强制让company-capf启用cache才好点.


#24

server端肯定需要考虑缓存之类的,但目前看瓶颈是在 client 端,尤其是解析 JSON 耗费太多资源。


#25

jsonrpc是个挺通用的协议, 用c来实现也挺好, 用途很广. async还是需要解析, 当然比现在的模式会好


#26

应该有一个缓存的协议

服务端发消息说,你的请求已经给过了,对应的ID是xxxxxx

不知道lsp现在有没有 这样就不用总是解析json了

还应该有一个预加载协议,比如java里通过import而得知应该加载哪些类

python里面也一样

不知道lsp里有没有这样的协议

以上的协议都需要有缓存

所谓的数据中心 真是哪里都用得上


#27

编辑代码时, 每个字符的修改都可能需要重新索引文件, 特别是当文件是别的文件要include或者导入的时候, lsp server的主要工作量应该是在索引, 而不在组装json.

对客户端来说, 如果瓶颈在解析json, 可以搞个独立线程来解析, json解析库全速工作时速度很快的.


#28

这种缓存, 我觉得客户端这边能缓存最近十条就够了, 缓存更多命中率不高, 意义不大.


#29

如果是JavaScript

当你输入 Array.

弹出的那些算一条 还是N条

如果再加上文档 惯用语句 函数参数 参考其他

又应该算多少条


#30

没用过javascript, 如果json消息很小, 其实没必要缓存.

如果json消息很大, 还可以定义一些协议来拆分, 类似于增量传输. 用户一次其实不需要看到很多信息.

比如一个补全有1万项, 可以先发100项过来, 后面用到了慢慢发过来. 1万项一次也显示不了, 大部分都用不到.


#31

没有 如果 啊


#32

这里你们不是说有提升么。。


#33

有一定提升,但很多场景下还是体验不好。也许是还没有全部完成吧,还得再等等看。


#34

我用 MacBookPro 13 (2011 early) 做了几组 json 测试:

(benchmark '100000 '(json-serialize nil))                ;; => Elapsed time: 1.794240s (0.542482s in 10 GCs)
(benchmark '100000 '(json-encode nil))                   ;; => Elapsed time: 0.223395s (0.204598s in 6 GCs)

(benchmark '100000 '(json-serialize [1 2 3 4 5]))        ;; => Elapsed time: 1.040232s (0.300108s in 11 GCs)
(benchmark '100000 '(json-encode [1 2 3 4 5]))           ;; => Elapsed time: 3.393036s (1.021399s in 39 GCs)

(benchmark '100000 '(json-parse-string "[true]"))        ;; => Elapsed time: 0.326448s (0.219570s in 8 GCs)
(benchmark '100000 '(json-read-from-string "[true]"))    ;; => Elapsed time: 3.172959s (1.022238s in 34 GCs)

(benchmark '100000 '(json-parse-string "{}"))            ;; => Elapsed time: 0.697704s (0.521620s in 18 GCs)
(benchmark '100000 '(json-read-from-string "{}"))        ;; => Elapsed time: 2.094041s (0.892319s in 32 GCs)

(benchmark '100000 '(json-parse-string json-string))     ;; => Elapsed time: 22.363518s (8.614685s in 321 GCs)
(benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 22.829035s (10.742630s in 378 GCs)

native 似乎没有明显提升,某些情况下持平甚至落后。


json-string:


#35

你似乎忘记说明json-string是什么了


#36

这么写肯定是一大块了,一行能写下就不会这么写。


#37

内容是什么倒是不重要。只是想稍微了解下json结构。比如有多少字,多大。这样。

或者你可以用pastebin来贴


#38

我用 https://github.com/syohex/emacs-parson/blob/master/bench/bench.json 提供的 json 字符串来测试,是想也同时比较一下 native 跟 dynamic module。

https://github.com/syohex/emacs-parson#benchmarkparson-vs-jsonel-standard-library 展示的测试结果,除第一项之外,其它都是 dynamic module 大幅领先。而 native 的最后一项几乎与 json.el 持平。

这个 json string 只有 20 多行,比起极端样本数据,更接近 lsp 通信的数据量。在我这里,benchmark 测试结果和实际的 lsp + native 使用体验是一致的:感受不到性能提升。


#39

用你这个测试代码和json测试文件在linux上跑了一下, 10年前的笔记本. 结果也是不太好.

Elapsed time: 31.353811s (18.417009s in 729 GCs)
Elapsed time: 42.392202s (29.418018s in 1165 GCs)

emacs编译用-O2, 测试结果显示, native json的性能仅提升了1/4, 而且时间还是在gc里. 挺尴尬啊.


#40

把测试文件扩大了以下, 到1000行大小, 运行1000次, 测试结果:

Elapsed time: 11.953426s (6.324524s in 250 GCs)
Elapsed time: 14.364171s (9.626586s in 386 GCs)

性能提升确实不多, 怪不得真实使用起来感觉不到差别.