-
Notifications
You must be signed in to change notification settings - Fork 765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pylance slows down when using the vulkan library #6351
Comments
…e expression contains thousands of entries. This is not typically found in hand-written code, but it can appear in computer-generated code. This addresses microsoft/pylance-release#6351.
…e expression contains thousands of entries. This is not typically found in hand-written code, but it can appear in computer-generated code. This addresses microsoft/pylance-release#6351. (#8903)
Thanks for the bug report and the clear repro steps. It looks like the vulkan library contains a bunch auto-generated code including several very large tuple expressions. One of them includes nearly 10K entries! Pyright (the type checker upon which pylance is built) has some O(n^2) logic when inferring tuple types. That explains why we're seeing such poor performance in this case. I've added an optimization to pyright to mitigate this issue. It now checks for very large tuples and falls back on a lighter-weight type analysis technique when it encounters very large tuple expressions. This change will be included in the next release of pyright and in some future release of pylance. |
Awesome, thank you for the quick fix! This will take a lot of the pain out of what was supposed to be a fun side project 😄 |
This issue has been fixed in prerelease version 2024.9.100, which we've just released. You can find the changelog here: CHANGELOG.md |
Environment data
Code Snippet
Libraries installed:
https://pypi.org/project/vulkan/
Repro Steps
python3 -m venv .venv
.venv/Scripts/python.exe -m pip install vulkan
code main.py
vulkan.VkAccelerationStructureCreateInfoNV()
After using this vulkan library, it feels like pylance is chewing on something very large and takes forever to provide assistance that used to happen instantly.
I noticed that this vulkan library has only a few source code files, but the ones that are there are pretty obnoxious. One has 22k lines of code, and another is just 12 lines of code, but one of those lines is a GIANT byte string (on disk, it's almost as big as the 22k line file). And to top it all off, the entire library is imported in the package's
__init__.py
asfrom vulkan._vulkan import * # noqa
Expected behavior
I'd expect that pylance could provide analysis promptly like it usually does, perhaps with an initial delay to process the large file once.
Actual behavior
Pylance takes a very long time to provide any intellisense, or to update problems it saw previously. "Go to definition" also takes a very long time.
It takes a long time for previously reported errors to resolve after being fixed for example. I was able to very casually open the snipping app and select this error and still have plenty of time remaining after the screenshot was taken where the message was reported. Re-introducing the error similarly takes a long time to re-recognize the problem.
For a small toy example like I reproduced here, the delay can be something like 30 seconds or so. But in my real project where I have a lot more files and code in my project, and many of those files import vulkan the time between updates and pylance assistance feels significantly longer.
I did notice that if I let things calm down and don't touch any of the code that touches vulkan, I can get normal pylance performance back, but if I touch any of the vulkan code and trigger pylance to re-check it again things slow down again.
If I use the TYPE_CHECKING variable to trick pylance into ignoring things I can mitigate the issue too, but then pylance is obviously upset about everywhere I use the vulkan library and obviously won't help me with it (and honestly, I'd really love to have some intelligence for these functions and constants)
Logs
No trace logs (I can capture them if needed), but I did run a cpu profile to hopefully capture what specifically might be taking a long time
pyright-2184-X0IqoqVQBmiO.zip
The text was updated successfully, but these errors were encountered: