High CPU usage when pow function exists in code
#1087
Comments
|
In general it seems like the performance has slowed down greatly. For example, even import json
f = open("msg.json", "r")
msg = json.load(f)takes sometime to load (~30s), but the pow was the most extreme case. So it might be a symptom of a larger issue |
|
OK, I think I found the culprit after spending a bunch of time messing with the settings. The issue goes away when I set |
|
coc-pyright uses |
|
I also am encountering the same issue with latest coc-pyright, spent like a day trying to figure out what is going on, indeed, something like a single |
|
Has there been any report to the Pyright maintainers with specifics of what exactly is taking so insanely long? I was unable to find any mention of |
|
@Krzmbrzl it's I haven't reported this to the Pyright repository because the function is internal and coc-pyright used this in a hack way. Pyright uses |
|
I am also experiencing similar issue where if the open I was scratching my forehead very hard since few days thinking it was an issue with my wifi/router connection, then it took me a while to debug this and search for this in this repo. coc-pyright v1.1.390 |
coc-pyright is often stuck at 100% CPU for minutes when it encounters certain functions, probably while generating inlay type hints. (see fannheyward/coc-pyright#1087) pyright itself doesn't provide these hints (MS keeps that feature hidden in the closed-source pylance VS Code extension), but the fork basedpyright does. Performance has been good so far, so switch to using that language server directly from coc.nvim coc-pyright also handled linting / formatting via e.g. ruff, so that functionality needs to be replaced as well. efm-languageserver acts like a proxy between LSP clients and linting / formatting tools. Multiple tools can be configured per language to provide linting suggestions or formatting files. coc.nvim is okay with running multiple language servers for a filetype, so basedpyright and efm-languageserver can be used together.
|
Oh, my dotfiles commit showed up here. I had to replace coc-pyright for now because of these performance reasons. I switched to using basedpyright because the original pyright, as mentioned, doesn't do inlay hints. Maybe this language server could also be something for coc-pyright? It's a true fork though so it has new checks and different defaults which might be a very unexpected change for users if this project would suddenly switch to it. It is, however, very performant. |
|
@Terr thanks for sharing! I just checked and there seems to be https://github.com/fannheyward/coc-basedpyright which looks like worth trying out |
|
@Cnly Great find! I didn't see it in the coc extensions list and didn't think to look further. I'm going to give it a try :) Edit: it works very well. I would say the same using basedpyright-langserver directly. |
Issue
CPU usage increases dramatically when there is a pow function in the code. The specific process seems to be this one
../start/coc-pyright/node_modules/pyright/langserver.index.js--node-ipc--clientProcessId=xxxxxxx.During this time, the CocAction
doHovercannot be called. CPU usage can stay high for 3+ minutes before it seemingly resolves,doHoverfunctionality is restored, and the parameter inlay hints are displayed.Minimum reproducable steps
Hopefully it's not just me. May also be an upstream issue, but I'm not sure.
Afternote: Also happens with
pow(1,1)What's the output of
:CocCommand pyright.versioncoc-pyright 1.1.365 with Pyright 1.1.365
What's the output of
:CocCommand workspace.showOutput PyrightThis was captured moments after opening the file. If I wait for it to resolve, then the output is 6000+ lines long, so I won't post it unless asked
The text was updated successfully, but these errors were encountered: