-
Notifications
You must be signed in to change notification settings - Fork 29.4k
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
Quick open is very slow #130479
Comments
I did a small amount of research into this and found that there is a proposal to allow Quick Open to be supplied by extensions. It's called Also there is an extension that uses this API to do exactly what I wanted cache the file list and return it quickly (well, maybe anyway): Unfortunately it hasn't been updated for 3 years so I'd be surprised if it still works. |
Here is the issue to stabilise |
You would probably be interested in the Remote-SSH extension which would let you run extensions and search directly on the remote, instead of over a slow network drive. What should happen is that we would keep the cache of files and search in that on subsequent searches. Not sure why it isn't working. You could follow the steps on this page to get the search logs which might tell us something. https://github.com/microsoft/vscode/wiki/Search-Issues Btw the extension you point to was a test extension that doesn't do anything different than what the built-in code does now. |
Sorry I probably wasn't clear - I am using the remote SSH extension to connect to a machine that itself uses NFS mounts.
Ah I will try that, thanks for the hint.
Also very useful information, thanks! |
Hmm unfortunately the logs don't show anything interesting.
The results appear at the same time as the last line, so it took 13 seconds. Could the reason be that the Remote SSH extension takes over handling of file name searching and doesn't cache them? I think it's closed source so might be hard to tell, but I'll try using VSCode over VNC instead of the Remote SSH extension and see if it makes a difference. |
There may be some info in the "Log (Remote Extension)" output channel as well |
I did some more debugging. Firstly it is still slow when running VSCode without the remote SSH extension (I run it via VNC instead). I can only test up to VSCode 1.48.2 because later versions crash with sigtrap on startup. :-/ I did also manage to compile VSCode 1.48.2 from source and run it (I had to compile a more modern version of glibc too and do some funky There's no logging at all in the existing code ( Do you know how I can add logging to |
Ah wait I found where the code ends up - in both of these files
|
Ah you can pass |
Hmm it seems like you are supposed to pass either |
Aha I had given up on this but then noticed the verbose option. If you run VSCode with It seems like the issue is that searches return a lot of results, and then sorting them is really slow: It's weird because the workspace only has 70k files in it:
|
Aha! If I run the So, I guess ultimately this isn't exactly a bug (although I reckon fuzzy matching 700k strings should probably take less time than 10 seconds), but it did take me like a whole day to figure out, including having to compile my own version of VSCode with extra logging. So it would be nice if it was a bit easier to diagnose. Here are a few ideas:
I'll close this issue though because I doubt any of those will happen and you have a bazillion bugs already. |
Thanks for doing that debugging. I would like to make the symlink issue more apparent but don't have time for it right now. That issue is mentioned in the wiki page I linked above. But really we should just be able to pop up a notification to the user when they may be encountering this. |
Does this issue occur when all extensions are disabled?: Yes
I am using VSCode on Mac to edit a large workspace (75k files) on a remote Linux machine. The Linux machine is a beast (48 core Xeon, 376 GB RAM) but it does have some limitations
ulimit -n
is only 65535.Opening files in the workspace on my local machine via Ctrl-P is basically instant, but on the remote machine it takes about 10 seconds (unless it was open recently).
find . -name ...
is much faster (it takes 1-2 seconds).Steps to Reproduce:
I appreciate that this is probably a worst case situation, but surely VSCode could scan the workspace and maintain a cache of all the filenames it has seen even if the filesystem itself is very slow? And I don't see why it is so much slower than
find
.The text was updated successfully, but these errors were encountered: