pylsp running very slowly

[alexrkaufman]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

Recently Zed switched to pylsp as the default linter. I am finding it runs much slower that pyright ran and I have had to change my settings to use pyright specifically instead of the default.

The gif below uses default zed settings for python linting as of 2024-11-22.

(It seems to lint better so I am happy with the switch otherwise.)

Environment

Zed: v0.162.5 (Zed) OS: macOS 15.1.1 Memory: 16 GiB Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

If applicable, attach your Zed.log file to this issue.

Zed.log

[osiewicz]

What is the source of the diagnostic in this video (this should be the prefix of it's contents)? As in, is it mypy or something else? I'm pretty positive that some of the issues with pylsp performance would have to be either fixed via our config (e.g. we should probably use dmypy instead of mypy) or upstream.

[alexrkaufman]

I am not sure, I tested it by disabling pylsp and telling zed to use pyright again. When I did this it was back to running quickly. Then I disabled pyright and any other linters so it would use the zed defaults which caused it to run slowly so I made the gif.

The file sizes I had open weren't that large. A couple of files, two or three open between 100-400 lines.

I can replicate it again and try to get additional information if that would be helpful.

[andaag]

@alexrkaufman can you share the config changes to move this back to pyright?

I have a codebase I'm working in where pylsp goes to 100% cpu and just sits there. Both completion and linting is completely broken since this change.

[carlosds731]

@alexrkaufman can you share the config changes to move this back to pyright?

I have a codebase I'm working in where pylsp goes to 100% cpu and just sits there. Both completion and linting is completely broken since this change.

Just use "language_servers": ["!pylsp", "pyright"]

"languages": {
    "Python": {
      "language_servers": ["!pylsp", "pyright"],
  }

[gitriff]

Yeah I am having the same issue. Running the same hardware as op. I can try to help debug this. Let me know if there is anything special you want me to capture (logs, profiling etc)

[afandian]

Another +1 here. Ubuntu 22.04.5, Intel i7, 16GB. Crawling slow with pylsp, snappy with pyright. I did notice a large number of pylsp processes running (about 10?). Not sure if that's expected.

[achimnol]

I just hit this issue, too. pylsp mypy is following the typing sequence with a few seconds delays per each.

[isatsam]

It seems that at least some of the lag comes from the new LSP aggressively scanning the entirety of your venv for "errors". Copying my own screenshot from this discussion:

Currently still observing these issues:

Zed: v0.166.2 (Zed)
OS: Linux Wayland arch unknown
Memory: 23.3 GiB
Architecture: x86_64
GPU: AMD Radeon Graphics (RADV RENOIR) || radv || Mesa 24.3.1-arch1.3

[54keesh]

I think pylsp is creating multiple processes and consuming a large amount of memory. Could you please check and see via ps if that is the case?

[RomanMIzulin]

Same but with pyright. Zed spawns a lot of pyright processes with 100% CPU usage on any big codebase even with setting that tells to run pyright only for opened files. OS: Manjaro Linux x86_64 CPU: 11th Gen Intel i7-1165G7 (8) @ 4.700GHz GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics]

[RomanMIzulin]

@isatsam try setting lsp.settings.python.analysis.diagnosticMode:"openFilesOnly"

[albas99]

I've also been having this issue from the day pylsp got adopted as the default LSP, based on my observation the slow down seems to be coming from pyflakes. I've noticed that when I'm calling a variable or a module that has already been imported, before I even finish writing the name of the variable I get a red underline indicating error but after I finish writing it, it then takes a couple of seconds for the error indicator to go away registering that it's a valid variable/module. We need more documentation on configuring pylsp specifically for Zed, I think that'll help alleviate some of the issues without having to push patches with lsp changes every time.

[martin-insulander-hiq]

It can be worth checking this issue from another project. https://github.com/techee/geany-lsp/issues/51 It seems like pylsp doesn't like too frequent lookups. In the example, it was the highlighting.

[yajo]

I recorded this screencast where I'm scrolling up and down in the zed code view with my mouse wheel, so you can see how it freezes when I just select a different python file. Also you can see the CPU peaks produced at the same time of Zed freezes. Then I repeat the test. There is at least one pylsp process per CPU. Maybe Zed should just span fewer processes:

https://github.com/user-attachments/assets/067693e9-f24a-428e-814d-b41faa768dda

Keeping in mind that Zed itself is another process, and one might have other LSP running... then maybe if I have a computer with 16 CPU like here, Zed should cap pylsp to use only 50% or 75% of them.

I guess that can be forced with a systemd slice as a workaround, but IMHO it should work out of the box.