Constant CPU usage from cpptools.exe scanning workspace

[jalfd]

On Windows, simply having VS Code open on a folder with a C++ project causes the cpptools.exe to almost constantly use some CPU. It doesn't use a full CPU core, but enough to occasionally make my laptop fan spin up.

The offending stack trace starts with

msvc::recursive_directory_iterator_utf8::enumerate_files_non_recursive
msvc::recursive_directory_iterator_utf8::recursive_directory_iterator_utf8
browse_engine::query_include_path_suggestions_impl
browse_engine::parse_file
browse_engine::parse_root
cpptools_context::parse_root
std::_Func_impl_no_alloc<`cpptools_context::cpptools_context'::`1'::<lambda_10_>,void,cpptools_context::browse_engine_update_action_and_task_token &&>::_Do_call
`msvc::deque_thread<cpptools_context::browse_engine_update_action_and_task_token>::defer'::`2'::<lambda_1>::operator()
msvc::thread_manager_t::do_work
msvc::thread_helper_t::thread_entry
thread_start<unsigned int (__cdecl*)(void *),1>

from there, it calls FindNextFileW() to iterate over the contents of the directory, and GetFileAttributesExW() presumably to get the modification time for each file. (Without having access to the cpptools executable I'm having to guess at why these calls are made).

The calls to GetFileAttributesExW end up taking a disproportionate amount of time, and I don't think they're necessary.

The FindNextFile function already returns attributes on each file, so GetFileAttributesEx() seems redundant. Alternatively, this could all be replaced with a call to GetFileInformationByHandleEx(), and both approaches would be over an order of magnitude faster. See the following blog post which documents optimizing pretty much the exact same use case:

https://www.wholetomato.com/blog/2024/11/14/how-to-query-file-attributes-50x-faster-on-windows/

I'd love to submit a PR myself, but again, I don't have access to the cpptools executable's source code.

I hope you can take a look at this. Even if the extension only uses a few percent CPU, doing so constantly on every machine it's running on adds up to a lot of wasted time and energy, if it can be trivially sped up.

[bobbrow]

Hi @jalfd,

@Colengms can correct me if I'm wrong, but our usage of GetFileAttributesEx() in this code path is only performed on folders and in that case it's looking for attributes that would indicate that the folder is a symlink. However, I believe the attributes we get back from FindNextFileW should be identical and we may not need to requery them if we pass this information down to the function that is doing the symlink test.

That said, if the extension is parsing more files than you would like, you can use the C_Cpp.files.exclude setting to trim folders you don't care about. If the fan noise is a bother and you just want to spread out the CPU usage over a longer period of time, you can use the C_Cpp.workspaceParsingPriority setting to do that. And once the parsing is complete, we shouldn't do another massive parsing pass again unless the database is invalidated (which is supposed to be rare). If you find that we're reparsing everything every time you launch VS Code, there may be something else going on that we'd be interested to understand because that is not the intended behavior.