@twig to be clear, with "cache" you mean this list of recently opened?:

Not the recently opened list, but an internal list of files in the project (not really sure how else to describe it)

Does vscode do a filescan every time we search for files to open? If so, my issue would lie outside of vscode

Yeah, the search service process shuts down after an hour of no activity, at which point the cache is lost.

We had the same discussion in #63094 with another very slow network drive.

How slow is the search? To me, that's the real issue. We can get some more info if you

• Run the command "Set log level" and change it to "Trace"
• Run the search again
• Show the search-related messages in the "Log (Window)" output panel
• e.g. SearchService#search: 220ms

@roblourens it's very slow (also a very big JS/front-end project with lots of files)

did you want me to time the search on initial load or after an hour of inactivity?

quick edit: my assumption was that the quick search would have fallen back to using data from the partially loaded explorer tree while it was still waiting for the scan to finish

wow my speeds (network drive via local wifi) aren't too bad compared to the other ticket

partially warm cache after loading and changing log level to trace

[2019-01-29 10:12:51.882] [renderer1] [trace] SearchService#search: 9997ms

after 1hr of inactivity

[2019-01-29 11:46:02.638] [renderer1] [trace] SearchService#search: 24992ms

in the meantime, is there an option for me to increase the timeout to 2hrs to avoid the daily nuisance?

@chrmarti do you think it would make sense to add a setting that just disables the timeout on the search service process? Ideally search just wouldn't be this slow but I don't know what we can do about this scenario.

@twig have you checked that any folders that you don't want to search are properly excluded? It could also be that we are 10000 files that you don't care about.

yep I've done what I can to reduce network noise

• files.watcherExclude and files.exclude clutter folders like node_modules, virtualenv, .git, *.pyc, , etc
• disabled git integration as much as possible
• no other activity is happening during those searches (no builds, no package updates, etc)
• excluded network folder from antivirus scans

I mean we do have a lot of files in our project, but I've done what I can to help vscode process it (it's become a habit after years of using Eclipse)

@roblourens Maybe just remove the timeout for all.

@twig How many files are in your workspace? Could you check what the rg command line is by running code --status while the search in QuickOpen is running?

I could, I think that for most people, if you are like me and have a bunch of idle vscode windows open, it's good to save many MB of memory by getting rid of idle search processes. But I could change the timeout to 3 hours or something.

Also we could just publish an extension that periodically runs vscode.workspace.findFIles to keep it alive 😁

@twig How many files are in your workspace? Could you check what the rg command line is by running code --status while the search in QuickOpen is running?

Sorry what am I doing where? Not too familiar with what you're asking me to do

But I could change the timeout to 3 hours or something.

Optional config with current value with default would probably be best for anyone that encounters this issue 🙏

I found a way to count the files in the project (via git ls-files | wc -l)

frontend project: 18914
backend project: 2040

You can run code --status in the terminal/command prompt to get the same info 😁

ooh terminal, gotcha! well, here it is in case you'll find it useful in any way

Version:          Code 1.30.2 (61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8, 2019-01-07T22:54:13.295Z)
OS Version:       Windows_NT x64 10.0.17763
CPUs:             AMD A10-5800K APU with Radeon(tm) HD Graphics   (4 x 3793)
Memory (System):  7.20GB (0.53GB free)
VM:               0%
Screen Reader:    no
Process Argv:
GPU Status:       2d_canvas:                    enabled
                  checker_imaging:              disabled_off
                  flash_3d:                     enabled
                  flash_stage3d:                enabled
                  flash_stage3d_baseline:       enabled
                  gpu_compositing:              enabled
                  multiple_raster_threads:      enabled_on
                  native_gpu_memory_buffers:    disabled_software
                  rasterization:                unavailable_software
                  video_decode:                 enabled
                  video_encode:                 enabled
                  webgl:                        enabled
                  webgl2:                       enabled
CPU %   Mem MB     PID  Process
    1       74   11444  code main
    0      269    7944     window (OLClient ΓÇó src\web\containers\Feed\FeedItemPost.jsx - Untitled (Workspace) - Visual Studio Code)
    0       65    6016       extensionHost
    0      616    4660         electron_node tsserver.js
    4       49   12896           electron_node typingsInstaller.js typesMap.js
    0       37    4748         "C:\Users\Twig\AppData\Local\Programs\Microsoft VS Code\Code.exe" "c:\Users\Twig\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\css-language-features\server\dist\cssServerMain" --node-ipc --clientProcessId=6016
    0       29    7216         C:\Users\Twig\.vscode\extensions\ms-vsliveshare.vsliveshare-0.3.1151\dotnet_modules\vsls-agent.exe --autoexit --pipe 00f3561d33a74057a64a0c7f6b4f5e0b --service https://insiders.liveshare.vsengsaas.visualstudio.com/
    0        5   12284           console-window-host (Windows internal process)
    0       22    6704       watcherService
    0       10   10248       electron-crash-reporter
    0        5   11100       winpty-process
    0       54    5864         C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    0        4    4384           C:\Windows\system32\cmd.exe /c ""C:\Users\Twig\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd" --status"
    0       35   13760             electron_node cli.js
    0       54    1112               "C:\Users\Twig\AppData\Local\Programs\Microsoft VS Code\Code.exe" --status
    0       31   14420                 gpu-process
    0        8   13752         console-window-host (Windows internal process)
    0       21   13008       searchService
    0       51    9848     shared-process
    0       54   15548     gpu-process

Workspace Stats:
|  Window (OLClient ΓÇó src\web\containers\Feed\FeedItemPost.jsx - Untitled (Workspace) - Visual Studio Code)
|    Folder (OLClient): more than 20432 files
|      File types: png(13661) gz(2993) jsx(1610) jpg(694) js(492) scss(453)
|                  css(81) dust(79) svg(56) html(38)
|      Conf files: package.json(3) makefile(2) grunt.js(2) launch.json(1)
|                  settings.json(1)
|      Launch Configs: node(2)
|    Folder (OLEngine): 3393 files
|      File types: py(1392) pyc(1048) html(382) jpg(265) wsdl(88) txt(38)
|                  png(38) sh(26) json(25) md(10)
|      Conf files: makefile(1) launch.json(1) settings.json(1)
|      Launch Configs: python(4)

@roblourens Another option might be to persist the cache. That would allow us to lower the timeout, helping with memory footprint across windows and cold-start performance with slow filesystems.

I'm fine with a setting for now, if you think that strikes the right balance.

Persisting the cache is a good idea. I think I'll add a setting for now just so it's usable, this seems to keep coming up. I wish I could repro it to figure out why rg is so slow here.

@twig @derekwallace You can enable search.maintainFileSearchCache in the next Insiders build and that should prevent the cache from being cleared. That doesn't really solve the problem but should help you.

I wish I could repro it to figure out why rg is so slow here.

Before I set up my own build of vscode and manually debug it, is there any other ways for me to provide details which may assist?

I don't think you will get much from building vscode. Here's something you can do though:

• Run code --status while the search is running
• In the list of processes, you should find a line under searchService that is the ripgrep process running with its exact command line args
• Run the same command in the terminal just to verify that it takes approximately as long as a file search does in vscode without the cache
• Then you could run it again with the --trace flag and that might give us some clue as to where ripgrep is spending its time when it's slow.

However, my guess is that we will just see that the shared drive is slow and there isn't much that can be done.

strange, I get this error message when trying it on the insider build

[main 2019-02-07T03:36:58.440Z] Warning: The --status argument can only be used if Code is already running. Please run it again after Code has started.

search service is taking about 34-37mb of memory

the rg process is given these args

     0       34    6584       searchService
    2        8    8064         "d:\Programs\Microsoft VS Code\resources\app\node_modules.asar.unpacked\vscode-ripgrep\bin\rg.exe" --files --hidden --case-sensitive -g !**/.git -g !**/.svn -g !**/.hg -g !**/CVS -g !**/.DS_Store -g !/.webpack-cache -g !**/*.pyc -g !**/node_modules -g !**/bower_components --no-ignore-parent --follow --no-config --no-ignore-global

With insiders you will have to use code-insiders --status.

rg.exe is using very little CPU. I think that is more evidence that the bottleneck is the network.

ahh good to know

yep, thought that'd be the case.
thanks everyone for the super quick turn-around for the issue!

some regressions I noticed so far

• the explorer tree takes MUCH longer to display after starting up with the option enabled. at least with stable build, the folders show up immediately after launch
• "go to file" doesn't seem to work very well (seems very forgetful). even after a search result has been found and results appear, searching again will cause another long wait

code-insiders : The term 'code-insiders' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

the explorer tree takes MUCH longer to display after starting up with the option enabled.

Interesting, this setting should not impact that, but if you are seeing a consistent difference you could file a separate issue.

"go to file" doesn't seem to work very well (seems very forgetful). even after a search result has been found and results appear, searching again will cause another long wait

That just sounds like the setting isn't working? How is it different from what you see without the setting?

With the setting disabled, it works as it does in stable release:

• start up vscode, explorer has the 2 folders in my workspace
• search for homepage.html
• wait a minute before results appear
• open homepage.html
• search for homepage.html and it appears instantly (from cache)
• everything works fine until its been idle for an hour, then cache is cleared

With the setting enable:

• start up vscode, explorer is empty and takes a very long time to load workspace
• search for homepage.html (doesn't matter while explorer is loading or after)
• wait a minute before results it appear
• open file
• search for homepage.html again
• wait a minute before it appears

I'm not sure what was changed but it feels like the cache is being cleared more often.

Im having issues with insiders build see #68280

From what i can see the new option makes no difference. in fact i dont think ive ever got results from the cache. iv eonly ever seen recently used files.

i checkec that rg.exe does run and completes (after many minutes). no cache with ctrl-p.

does the change really work?
Ive tried it on latest stable and i can see no improvement.
the quick find rarly if every has a cache of my files.

No it seems to have made no difference.
Cache doesn't seem to work.
Only wanted an option to increase the cache duration

Gonna close this issue as remote dev via ssh has significantly improved my workflow

Feel free to re-open if needed