Lsp-mode: Performance issues with Dart

[jpprime]

Describe the bug
Whenever using lsp-mode in a Dart project I have observed some small performance issues and some big performance issues.

First the small one. When trying to complete something, either using company-mode or not, if the completion list is too big, for example typing 'a' and then manually triggering the completion on a large scope, like on the first line of a new class, which is inevitably going to show a lot of options since you do have lots of options, the UI gets frozen while the completion list is being generated. That happens with lsp-prefer-capf on and off, and it also happens even if company-mode is disabled and using the native Emacs completion system. It is alo worth noting that the time th UI remains frozen is a tiny bit smaller (at least I think so, it might be confirmation bias, because some times I notice this and some times I don't) when lsp-prefer-capf is set to t. This UI freezing doesn't happen with company-mode enabled outside of a buffer with lsp-mode disabled. Other instances of lag on the UI also happen. Sometimes when I undo a command it takes some time (usually something under but close to a second) to display the change (something that does not happen even on large, like, really large files when lsp-mode is not being used) and even on movement (another maybe important information is that I use evil-mode). I know this might be nit picky, but I don't observe this kind of issues when using something like VSCode (I've used it only for a day in order to test if the performance issues also happen there, but I would really love to have a snappy Emacs because I can't stand using VSCode).

Now for the big one. When trying to find definitions with lsp-ui-peek-find-definitions for something that is defined in the core of the language or in the core of Flutter (I'm using it to develop Flutter apps, if that is of any help), Emacs starts to become increasingly slow and in a matter of thirty something seconds it becomes unusable. Sometimes it gets back to being usable after some minutes, but those UI lags I've mentioned before get worse. This slowness also happen if I try to open one of those big files from the Flutter framework of Dart core libraries and start lsp-mode manually. This, however, does not happen when using lsp-find-definition, it just takes me to the file where the definition was found and doesn't start the server (note that I tell it to "Do nothing", by pressing n, whenever it asks me what to do with the project on those big files) and everything keeps running smoothly. I need to manually kill the language server and start it again on the project I'm working on.

Unfortunately I haven't had the time to test with other language servers besides Dart, and I would appreciate if you would provide me a complete project in other language in order for me to test it.

To Reproduce
I would love to provide the project I'm working on, but it is private. Although I've noticed the same behavior happen on small projects like this one I was doing while learning Flutter: destini-challeng-completed. I'm also adding gists for my LSP, company, and dart-mode configuration here (I've also added definitions for some of the macros I use on my configuration); and you can take a look at my complete Emacs configuration, in case it is of any help, here.

Expected behavior
I would expect lsp-mode to behave better, in terms of performance, or equal to VSCode, without those UI lags and freezes or complete freeze in the case of lsp-ui-peek-find-definitions.

Which Language Server did you use
lsp-dart

OS
Currently on Debian 10, using Emacs 28 from the Emacs snapshots repository.

Error callstack
There is no error and Emacs doesn't exactly "hangs", it just becomes really really really slow. On the gist mentioned above I've also included the contents of *lsp-log* with lsp-print-performance set to t and the profiler I ran so that you can visualize it in you own Emacs. It is also worth noting that I've tested to see if those behaviors occur with different values of gc-cons-threshold and read-process-output-max.

I'd like to close by saying thank you for your contribution and letting you know that I would like to contribute to lsp-dart if needed, even though I'm not that well versed in Emacs Lisp.

[ericdallo]

This happened to me all the time with emacs 26, after I changed to emacs 28, it resolved the issue. I think that the native JSON parser feature on emacs 27 resolved the problem.

[zoechi]

When trying to find definitions with lsp-ui-peek-find-definitions for something that is defined in the core of the language or in the core of Flutter (I'm using it to develop Flutter apps, if that is of any help), Emacs starts to become increasingly slow and in a matter of thirty something seconds it becomes unusable.

I have seen this behavior in various languages (Rust, OCaml, Elm)
Keeping a file from a dependency or core library open makes Emacs mostly unusable.

I had some serious performance issues recently with Dart as well. Editing Dart with LSP enabled cause kswapd to utilize 100% CPU all the time. After every edit it took a minute to become responsive again. After tweaking memory assignment for the VM this seems fixed and Dart in Emacs works great.

I don't know yet if this improves Rust, OCaml, Elm as well. Didn't have time yet to check.

GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0) of 2020-03-31

[yyoncho]

@jpprime as per https://github.com/emacs-lsp/lsp-mode#reporting-performance-problems can you provide the corresponding performance reports?

[jpprime]

@jpprime as per https://github.com/emacs-lsp/lsp-mode#reporting-performance-problems can you provide the corresponding performance reports?

I've included the output of the *lsp-log* buffer with lsp-print-performance set to true on the gist linked on the issue.

[yyoncho]

I've included the output of the *lsp-log* buffer with lsp-print-performance set to true on the gist linked on the issue.

I am looking for the profiler report as described starting from https://github.com/emacs-lsp/lsp-mode/blame/master/README.org#L221

[jpprime]

I've included the output of the *lsp-log* buffer with lsp-print-performance set to true on the gist linked on the issue.

I am looking for the profiler report as described starting from https://github.com/emacs-lsp/lsp-mode/blame/master/README.org#L221

Oh, I'm sorry, I thought I had included it in the gist, my bad. It is now in the gist as profiler-report completion for the profiler regarding the completion locking the UI and profiler-report find definitions for the slowness issue when using lsp-ui-peek-find-definitions and the raw content is here and here respectively.

[yyoncho]

The performance log shows that you are not using native json. Please follow the instructions in the performance section to verify that your emacs is compiled with emacs native json support. If your emacs has native json support re-install lsp-mode to make sure it is byte-compiled by emacs that has native json support. In addition to that you have set lsp-print-io to t - please make sure that you are performing performance testing with lsp-print-io set to nil.

I am closing the issue - please reopen it after applying the advices in the performance section and providing the requested information as described in the https://github.com/emacs-lsp/lsp-mode#reporting-performance-problems

[jpprime]

Well that is odd since emacs-version tells me I'm using Emacs 28... Nonetheless, I will build Emacs 27, test, and report back here for anyone with the same issues. If I would like features added to lsp-dart.el should I add it to the pinned issue for the wishlist? Thank you once more for the work and attention!

[yyoncho]

Well that is odd since emacs-version tells me I'm using Emacs 28...

This does not guarantee that emacs has been built with native json support since it has to be enabled during built time.

If I would like features added to lsp-dart.el should I add it to the pinned issue for the wishlist?

You may open a separate issue.

[yyoncho]

Well that is odd since emacs-version tells me I'm using Emacs 28...

And as I mentioned once you have compiled the package using an old version of lsp-mode it will still use the slow elisp implementation since we are performing some optimizations during byte-compilation.

[zoechi]

native json support is enabled by default, but only takes effect if libjansson-dev (Debian) is installed.

Thanks for pointing that out. Just rebuilt Emacs and hopefully will enjoy much better performance \o/