还是觉得有缓存的更好
这样能减轻lsp的工作量
redis还能存储到文件 可以将常用的包的补全、文档什么的保存起来
elpa里有eredis
更多的工作应该是在lsp-server那里
lsp客户端行为不一定一样, 比如company-capf加eglot, 每输入一个字符company-capf都会重新请求补全项目(即使company的补全菜单还有补全项没用完), 卡的简直没法用. 最后改代码强制让company-capf启用cache才好点.
server端肯定需要考虑缓存之类的，但目前看瓶颈是在 client 端，尤其是解析 JSON 耗费太多资源。
jsonrpc是个挺通用的协议, 用c来实现也挺好, 用途很广. async还是需要解析, 当然比现在的模式会好
应该有一个缓存的协议
服务端发消息说，你的请求已经给过了，对应的ID是xxxxxx
不知道lsp现在有没有 这样就不用总是解析json了
还应该有一个预加载协议，比如java里通过import而得知应该加载哪些类
python里面也一样
不知道lsp里有没有这样的协议
以上的协议都需要有缓存
所谓的数据中心 真是哪里都用得上
编辑代码时, 每个字符的修改都可能需要重新索引文件, 特别是当文件是别的文件要include或者导入的时候, lsp server的主要工作量应该是在索引, 而不在组装json.
对客户端来说, 如果瓶颈在解析json, 可以搞个独立线程来解析, json解析库全速工作时速度很快的.
这种缓存, 我觉得客户端这边能缓存最近十条就够了, 缓存更多命中率不高, 意义不大.
如果是JavaScript
当你输入 Array.
弹出的那些算一条 还是N条
如果再加上文档 惯用语句 函数参数 参考其他
又应该算多少条
没用过javascript, 如果json消息很小, 其实没必要缓存.
如果json消息很大, 还可以定义一些协议来拆分, 类似于增量传输. 用户一次其实不需要看到很多信息.
比如一个补全有1万项, 可以先发100项过来, 后面用到了慢慢发过来. 1万项一次也显示不了, 大部分都用不到.
没有 如果 啊
这里你们不是说有提升么。。
有一定提升，但很多场景下还是体验不好。也许是还没有全部完成吧，还得再等等看。
我用 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:
2 个赞
你似乎忘记说明json-string是什么了
这么写肯定是一大块了，一行能写下就不会这么写。
内容是什么倒是不重要。只是想稍微了解下json结构。比如有多少字，多大。这样。
或者你可以用pastebin来贴
我用 emacs-parson/bench.json at master · syohex/emacs-parson · GitHub 提供的 json 字符串来测试，是想也同时比较一下 native 跟 dynamic module。
GitHub - syohex/emacs-parson: JSON parser with dynamic module feature 展示的测试结果，除第一项之外，其它都是 dynamic module 大幅领先。而 native 的最后一项几乎与 json.el 持平。
这个 json string 只有 20 多行，比起极端样本数据，更接近 lsp 通信的数据量。在我这里，benchmark 测试结果和实际的 lsp + native 使用体验是一致的：感受不到性能提升。
用你这个测试代码和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里. 挺尴尬啊.
把测试文件扩大了以下, 到1000行大小, 运行1000次, 测试结果:
Elapsed time: 11.953426s (6.324524s in 250 GCs)
Elapsed time: 14.364171s (9.626586s in 386 GCs)
性能提升确实不多, 怪不得真实使用起来感觉不到差别.