亲测:lsp-python-ms vs pyls 性能

lsp

#1

今天实在忍受不了pyls+lsp-mode 慢如龟速的补全,主要是针对pandas和numpy大型库的情况下,几乎无法使用。折腾了下 https://github.com/emacs-lsp/lsp-python-ms ,使用了dotnet-sdk在macOS下成功编译,将vscode里的御用lsp搬过来,果然速度快多了。Microsoft 还是很良心的,居然成了开源届的一股清流。如果有相同困扰的童鞋可以试试这个了。

Update: 使用Centaur可以自动下载mspyls可执行包,不需要任何额外操作和配置了,支持Windows,macOS和Linux。


#2

lsp-python-ms确实很不错,而且装起来不是太麻烦


#3
(use-package lsp-python-ms
  :ensure nil
  ...)

我使用的时候发现 :ensure 那一项需要替换为 :demand 。不是很明白这么做的原因。


#4

持续关注一下,之前用 lsp-python 因为不能自定义 flychecker 所以换回 PyCharm 了。大型的 Python 项目感觉还是 PyCharm 更加方便一些,反正我把 PyCharm 的按键方式改为了 Spacemacs 的按键,基本上和 Emacs 可以无痛切换。


#5

不需要啊,:ensure 是确保package已下载,demand是让package开机load,没啥影响


#6

原来是这样,之前情况是配置后还是会提示 no language server,需要添加一项demand


#7

因为user-package设置了defer,这时候就需要demand强制加载。看看use-package-always-ensure变量就清楚了。


#8

我刚刚在 macOS 10.12 试了一下,Microsoft.Python.LanguageServer 进程也起来了,但似乎 c/s 之间没有任何通信,打开调试信息 *mspyls* 缓冲是空的。


#9

检查一下*lsp-log*这个buffer。


#10

刚装完的时候貌似索引超久,然后一下显示lsp task canceled之类。


#11

要多等一会儿。mspyls的策略是全部索引缓存起来,下次查询就快了。vscode里也是这样的。


#12

这个 buffer 我之前也是看过的,除了打印一堆 search path 之外,并未提示异常。

那可太久了,我昨晚电脑没关,今天又在外面一天,傍晚五点多才回来。

不过的确是启动过程没有完成,我看到有人提 ISSUE 了:LSP never reach “started”?


#13

我也报这个错,哎,同样的server在vscode上体验完美的简直爆炸,emacs里的体验是恶心的想死。咋差距那么大涅,难道这就是拿工资和不拿工资的差距 :joy:

我有个梦想:希望有一天emacs里python的lsp至少能比anaconda-mode 体验一样好 (感觉要做到vscode一样的体验,有点奢求)


#14

其实在我的机器(一台MBP2015和一台Ubuntu服务器)上,lsp的效果比anaconda-mode好很多呢。起码补全的速度更快,而且lsp的补全还是模糊补全,anaconda-mode能否模糊补全我不太清楚。


#15

我最晚的一次是在6月6号编译的mspyls,这个版本还是能够工作的。你不妨checkout到这之前的commit之后重新编译一下,看看能否解决你的问题。


#16

Emacs 如果还是单线程就永远不可能了。

据我的观察,同样的 server,在 VSCode 下也是要转圈圈等待的,而且有的也很慢,要等很久才会补全,但是 vsc 不会阻塞用户操作。Emacs 就不同了,一旦请求发出去,在得到应答之前,用户动弹不得。


#17

这个结论是如何得到的?lsp-mode用的是异步请求,在得到应答之前你的操作也不会被阻塞的吧


#18

打开 lsp-log-io看看有什么记录。我这里没有问题,同样使用pandas和numpy速度很快。 我录了一小段视频,可以看看


#19

lsp-mode现在是一些细节还有待雕琢,但是大部分功能是没有问题的。性能需要server和client共同改进。至于说阻塞UI的问题,我没有碰到过,lsp-mode是异步请求的,目前瓶颈是json parser,但在27中有明显改善。


#20

这个不能算error,应该是一个info或者warning。出现后还是能正常使用。进程管理器中看看server进程是否还在索引工作(CPU占用高),等索引完了使用很顺畅。