You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Not checking files.exclude during the initial directory iteration can make the extension unusably slow for large folders #3123
I added a symlink to a huge folder with hundreds of thousands of subfolders. Even though the symlink is added to the files.exclude, all the folders are still being iterated over, making everything too slow, particularly if recursive includes are used (because takes "forever" to iterate through all the folders). I don't know how common this is. The root problem is that we're not checking folder exclusions when we generate our initial list of directory entries, so all the subfolders of excluded folders are still added, and later every folder ends up checking checked against the files.exclude, which is expensive. As a workaround, I'm removing the symlink to the large folder.
One thing I want to make sure of is I have an extension and a large scale project that doesn't use symlinks, but uses the API provider where some of the provided headers are in a files.exclude folder. This seems pretty common too, especially with things like generated headers in something like a CMake build, where the generated file gets placed in the build folder. I want to make sure a fix for this does not break that workflow, as that is very important to us, and likely others. Want to make sure both go to definition and full intellisense still works as well.
Hmm...we already have files.exclude checkers that avoid parsing those files, but we apply the exclude filter after the huge list of folders is already generated (i.e. checking for exclusion on 100k folder unnecessarily). So Go to Definition on a target in a files.exclude folder or recursive includes for folders matching a files.exclude is not expected to work currently. Maybe we could use search.exclude or add a new intelliSense.exclude setting.
I had the exact same issue and after setting files.watcherExclude it stopped consuming CPU. Although I have a feeling that it is more of the VSCode issue instead of this plugin as even with NO PLUGIN installed, behaviour was same until I set files.watcherExclude.
changed the title [-]Adding a symlink to a huge folder makes the extension unusably slow (even with files.exclude)[/-][+]Not checking files.exclude during the initial directory iteration can make the extension unusably slow for for large folders[/+]on Aug 13, 2020
changed the title [-]Not checking files.exclude during the initial directory iteration can make the extension unusably slow for for large folders[/-][+]Not checking files.exclude during the initial directory iteration can make the extension unusably slow for large folders[/+]on Aug 13, 2020
Activity
ThadHouse commentedon Feb 3, 2019
One thing I want to make sure of is I have an extension and a large scale project that doesn't use symlinks, but uses the API provider where some of the provided headers are in a
files.excludefolder. This seems pretty common too, especially with things like generated headers in something like a CMake build, where the generated file gets placed in the build folder. I want to make sure a fix for this does not break that workflow, as that is very important to us, and likely others. Want to make sure both go to definition and full intellisense still works as well.sean-mcmanus commentedon Feb 4, 2019
Hmm...we already have files.exclude checkers that avoid parsing those files, but we apply the exclude filter after the huge list of folders is already generated (i.e. checking for exclusion on 100k folder unnecessarily). So Go to Definition on a target in a files.exclude folder or recursive includes for folders matching a files.exclude is not expected to work currently. Maybe we could use search.exclude or add a new intelliSense.exclude setting.
terrisgit commentedon Aug 3, 2019
Given that I check my .vscode directory into git, I'd rather put 'excludes' in c_cpp_properties.json (See https://github.com/microsoft/vscode-cpptools/blob/master/Documentation/LanguageServer/c_cpp_properties.json.md).
For now (but this doesn't work due to this bug), you're supposed to add patterns via Preferences/Settings .. then search for "exclude".
jinay1991 commentedon Oct 17, 2019
I had the exact same issue and after setting
files.watcherExcludeit stopped consuming CPU. Although I have a feeling that it is more of the VSCode issue instead of this plugin as even with NO PLUGIN installed, behaviour was same until I setfiles.watcherExclude.The process consuming CPU was
watcherHelper4 remaining items
[-]Adding a symlink to a huge folder makes the extension unusably slow (even with files.exclude)[/-][+]Not checking files.exclude during the initial directory iteration can make the extension unusably slow for for large folders[/+][-]Not checking files.exclude during the initial directory iteration can make the extension unusably slow for for large folders[/-][+]Not checking files.exclude during the initial directory iteration can make the extension unusably slow for large folders[/+]michelleangela commentedon Apr 7, 2021
Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/1.3.0-insiders4
michelleangela commentedon Apr 14, 2021
Fix is released in the 1.3.0 release version https://github.com/microsoft/vscode-cpptools/releases/tag/1.3.0