那就不清楚了。
Maybe it is fixed by lsp-ui-doc: fix handling of markdown MarkupContent by Khady · Pull Request #249 · emacs-lsp/lsp-ui · GitHub but I want to unify the logic here and in the logic used in lsp-describe-thing-at-point
.
一位中文输入法常年崩溃的坛友
总结精辟。。
崩溃的不只是我一个吧
emacs的json是借用外部的库实现的
并不是从0开始
I upgraded lsp-ui
to the latest version, but I don’t know how to enable markdown format for the doc in python-mode
. It’s still displayed as plaintext in chlld-frame, but displayed correctly in buffer via lsp-describe-thing-at-point
.
Apparently not all the cases are covered. I will try to finally fix that code as part of 6.1 release or at least I will unify it with lsp-mode lsp-describe-thing-at-point . We are now almost done with the lsp spec.
If you are looking for optimization of json parsing you could patch json parsing like that, it speeds up native parsing ~2 times.
static Lisp_Object
json_make_string (const char *data, ptrdiff_t size)
{
/* return code_convert_string (make_specified_string (data, -1, size, false), */
/* Qutf_8_unix, Qt, false, true, true); */
return make_specified_string (data, -1, size, false);
}
有一个 commit 对这个做了修复,就是不知道效果怎么样
有改善:
- emacs-nightly-2019-03-11
(benchmark '100000 '(json-serialize nil)) ;; => Elapsed time: 0.781194s (0.459996s in 22 GCs) (benchmark '100000 '(json-encode nil)) ;; => Elapsed time: 0.717249s (0.696107s in 14 GCs) (benchmark '100000 '(json-serialize [1 2 3 4 5])) ;; => Elapsed time: 1.151345s (0.485101s in 24 GCs) (benchmark '100000 '(json-encode [1 2 3 4 5])) ;; => Elapsed time: 3.946905s (1.711959s in 88 GCs) (benchmark '100000 '(json-parse-string "[true]")) ;; => Elapsed time: 0.430584s (0.365047s in 18 GCs) (benchmark '100000 '(json-read-from-string "[true]")) ;; => Elapsed time: 3.815848s (2.016469s in 77 GCs) (benchmark '100000 '(json-parse-string "{}")) ;; => Elapsed time: 0.939729s (0.807201s in 41 GCs) (benchmark '100000 '(json-read-from-string "{}")) ;; => Elapsed time: 2.700354s (1.535654s in 73 GCs) (benchmark '100000 '(json-parse-string json-string)) ;; => Elapsed time: 28.358048s (15.606600s in 729 GCs) (benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 30.516164s (18.759847s in 857 GCs)
- emacs-nightly-2019-05-05
(benchmark '100000 '(json-serialize nil)) ;; => Elapsed time: 0.691653s (0.346536s in 14 GCs) (benchmark '100000 '(json-encode nil)) ;; => Elapsed time: 0.152464s (0.273960s in 14 GCs) (benchmark '100000 '(json-serialize [1 2 3 4 5])) ;; => Elapsed time: 0.540319s (0.310708s in 15 GCs) (benchmark '100000 '(json-encode [1 2 3 4 5])) ;; => Elapsed time: 5.365478s (2.094981s in 88 GCs) (benchmark '100000 '(json-parse-string "[true]")) ;; => Elapsed time: 0.409175s (0.346409s in 18 GCs) (benchmark '100000 '(json-read-from-string "[true]")) ;; => Elapsed time: 3.157826s (1.607454s in 77 GCs) (benchmark '100000 '(json-parse-string "{}")) ;; => Elapsed time: 1.191392s (1.010268s in 41 GCs) (benchmark '100000 '(json-read-from-string "{}")) ;; => Elapsed time: 3.097365s (1.657493s in 73 GCs) (benchmark '100000 '(json-parse-string json-string)) ;; => Elapsed time: 15.310692s (10.497624s in 496 GCs) (benchmark '100000 '(json-read-from-string json-string)) ;; => Elapsed time: 31.160639s (18.475476s in 858 GCs)
感觉GC影响很大呀,是不是调下gc-cons-threshold
性能更好?
Emacs 27 如果能解决 lsp 卡顿的问题岂不是逆天了?
emacs 26.2和27.0.50用lsp-mode和mspyls写python的代码,感觉2个版本的速度差不多。没什么区别。
我之前用26.2 有点卡,现在用的27.05,基本没有卡的情况很流畅;也可能是我的电脑的问题
27改进了一些backtrace相关的内容,让debug更方便了,比如
echo '(error "Break the core!")' >> ~/.emacs.d/init.el
emacs --debug-init
得到backtrace
会提示你出错的具体在文件的哪个位置。妈妈再也不用担心我改配置多打一个括号了。
Emacs 27 加了一个新的API string-distance
, 用C实现的,比Lisp实现快100倍。建议用法(string-distance str1 str2 t)
第三个参数是t的话对unicode宽字符不做特殊处理,这样速度更快。
典型应用是查找和当前文件相关的文件,如已打开hello.cpp
,找hello.hpp
,或从mycomp.jsx
找mycomp.service.js
.
刚刚用上emacs-27.0.50,在windows10,明显感觉要比emacs-26.3要流畅,推荐升27