Support lazy loading individual virtualenvs in a multi-root workspace #6009
Comments
|
good idea. something I will do soon. |
bschnurr
added
the
fixed in next version (main)
|
This issue has been fixed in prerelease version 2024.6.102, which we've just released. You can find the changelog here: CHANGELOG.md |
|
🙏 Y'all rock! Thank you so much! |
|
I should explain how to use it. Well actually @heejaechang would be better at doing that. He implemented it :) |
|
Was just about to ask, since it doesn't seem to be the default -- I don't see the setting under |
|
Hi pcasdf. there is no setting. it is a new default behavior. we were postponing indexing third party libraries until there is a file opened from a workspace, but we didn't do that for user files. now we will postpone any file (third party or user file) until a file is opened for the workspace. |
|
@heejaechang is it intended that given this structure: if I open |
To clarify, my hope is that I can open a file in project a, and only then will project a begin to index, and project b and c should not try to index until I open a file under their tree. |
|
are you using multi root workspace as in vscode's multi root workspace support? or are you using it as different meaning? if you have multi root workspace where root is opening if you have 1 workspace as |
|
We do use multi-root project with structure similar to: But I also removed root, leaving it as: And I see output similar to: Maybe I misunderstand how the indexing works, but this step usually seems to take a lot of CPU. I do see now a separate step when I open a file under a separate project: So is this where the actual indexing occurs? |
|
I think I understand now that that's where the indexing occurs. Sorry for my confusion! |
|
ya, the second one is when indexing started. so if you are saying the first one takes a lot of cpus, it could be something else taking time. also, you can do |
don't worry about it, anyway, if there is other perf (CPU) issue outside of indexing, can you provide us some logs so we can take a look what is going on? basically steps you need to do is
it would help us a lot to find out where CPUs are used for the part you mentioned. |
|
I see now that indexing appears to complete fairly quickly, even in a large 7k Python file sub-project, if VS Code has already loaded all extensions and Pylance has fully loaded and reached the idle state. But when opening a file after the Python extension is just beginning to load, it appears that the background analysis tasks may be blocking before allowing indexing to begin. This is only a problem for us since we have so many projects, or "service instances" as they're named in the output. When we start VS Code and open our first Python file of that session, we usually have to wait about 1-2 minutes before Intellisense begins to work. Afterwards, opening files in other projects is fairly fast, even for those that hadn't been indexed yet. This isn't a terrible experience, but I would love to see a speed up in that initial time from start up to working Intellisense. Here are two profiles. The first one was after disabling indexing, and the second is after enabling indexing. Edit: |
|
no worry. thank you for providing the data! |
|
found the issue. dupe of #6046 |
My company uses a monorepo and multi-root VS Code workspace with over 40 Python projects. On initial startup of VS Code, the Python extension takes a ton of CPU and memory because it starts indexing every virtualenv. I really wish there were a config that allows us to choose to only begin indexing a virtualenv when a file within that project / sub-root is opened.
The text was updated successfully, but these errors were encountered: