Closed ju-kreber closed 8 months ago
We released 2021.2.2 yesterday, and your bug is reported on 2021.2.1, can you retry with the latest version?
My guess is that it won't, though, as your logs say:
[BG(1)] checking: /home/jens/pylance_issue/test.py (70475ms)
[Info - 15:43:15] [BG(1)] Long operation: checking: /home/jens/pylance_issue/test.py (70475ms)
[BG(1)] analyzing: /home/jens/pylance_issue/test.py (70478ms)
[Info - 15:43:15] [BG(1)] Long operation: analyzing: /home/jens/pylance_issue/test.py (70478ms)
Is test.py
exactly your code snippet? It's hard for me to imagine that checking that file takes 70 seconds...
Hi, thanks for the reply!
Yup, it's the same with 2021.2.2 and as mentioned above I also experience the same with the insiders version.
Yes, this is exactly the file. I'm in an otherwise empty folder and this is the only file open.
I know this whole thing is weird, but it happens exactly as I'm reporting it. I isolated the issue with sympy
by commenting out lots of other imports in a larger project; none of those seemed to have a similar problem...
This is related to https://github.com/microsoft/pyright/issues/1439. I don't see any obvious ways to make this work better. I offered some suggestions in the linked bug, but none of them are great solutions unfortunately.
We're looking into this, seems like a case for profiling.
This is related to microsoft/pyright#1439. I don't see any obvious ways to make this work better. I offered some suggestions in the linked bug, but none of them are great solutions unfortunately.
Thanks for the link! Indeed, disabling useLibraryCodeForTypes
circumvents the issue. Of course, one also loses useful functionality :/
Since sympy was the only problematic package for me, I'm now using
sympy = importlib.import_module('sympy')
as a workaround to prevent pylance from analyzing it, but keeping useLibraryCodeForTypes
True otherwise.
We are exploring the use of partial type stubs for this package. By stubbing some of the key types, it looks like we'll be able to dramatically reduce the computational cost of inferring the remaining types.
That sounds great! Thank you so much for working on this, I'm looking forward to trying it out!
I can confirm this issue. By removing the reference to sympy
, VS Code returned to normal behaviour.
To add an information: this issue happens for me when I import the solve
function of sympy
I had this:
from sympy import symbols, pretty, Wild, solve, sqrt, latex, Rational
When I remove solve
from the import, the performance gets better.
Sounds like a duplicate of https://github.com/microsoft/pylance-release/issues/1388.
Vice versa, actually. Will close that issue.
Per #1895, the next release includes a performance change that trades super, super long analysis times in sympy for nearly instant results with imperfect type info.
Getting these accurate will take stubs or changes upstream, but that's another issue.
This issue has been fixed in version 2021.10.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#2021100-6-october-2021
I'm having this issue now. I checked with different versions; it seems to have been fixed (atleast) from v2021.10.0 (as you said) to v2023.11.10, while v2023.12.1 and later versions are giving me the issue.
I'm having this issue now. I checked with different versions; it seems to have been fixed (atleast) from v2021.10.0 (as you said) to v2023.11.10, while v2023.12.1 and later versions are giving me the issue.
@jhmni, this is a really old issue. You'd be better off opening a new one. We'd need the information outlined here: https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#filing-an-issue
Okay the information in this bug is enough for me to reproduce. Reopening.
Simply have sympy installed and add this code:
import sympy
def f():
sympy.acos(42)
Add a space to the file.
It takes 14 seconds for pylance to analyze the file:
2024-02-21 10:25:31.031 [info] [Info - 10:25:31 AM] (19620) [BG(1)] Long operation: analyzing: file:///c%3A/Users/rchiodo/source/testing/Testing_Pyright/test_sympy.py (13953ms)
Going to try this with Pyright CLI. Likely reproduces there.
Yes it does but it seems this has already been discussed: https://github.com/microsoft/pyright/issues/7159
I think this means pylance doesn't support sympy.
Closing this for now. We'll discuss if there's anything we can do in the Pyright issue: https://github.com/microsoft/pyright/issues/7159
Our next prerelease version of Pylance will have type stubs for sympy bundled with it. That should make sympy run a LOT faster. Local tests show a speedup of 100x.
Environment data
Code
Expected behaviour
Pylance analyses the file quickly, reasonable CPU consumption
Actual behaviour
100% CPU usage (single core) for a while (1 or 2 minutes), starts again when making trivial changes to the file (e.g. adding a space). While obtaining the logs I noticed that it takes about a second to produce a new log line during checking many of the sympy files initially, definitely not the few milliseconds that are printed.
Logs