These are observations by Sven Brauch taken from a phabricator review. Not taking credit, nor taking the challenge to address the reported issue just yet. I may in due time if no one more qualified beats me to it.

The observations probably pertain to the cmake project plugin, in "CMake Server" mode (which is roughly 4x slower than the json-based importer in my own benchmarks).

>>>>>>

It indeed takes ages to import the project, and I couldn't figure out why ... it is certainly not CPU load. I looked in perf, the CPU time spent in importing the project is quite low.
In fact, the code model generation (which seems to be the last step in the import AFAIU) finishes relatively quickly here (after something like 5 seconds), but then it still takes like 30 seconds for the import to finish. I don't know where that time is spent.

This is a bug, something is waiting too long for something else. Let's find the bug instead of introducing checkboxes to work around it.

Here's the two things that are broken and need fixing:

1. FileManagerListJob has a queue of directories to list. It processes those sequentially, and after listing each, it goes through the event loop (async slot invocation) to list the next. This takes aaaaaages for lots of directories to list, which are mostly spent waiting and not in actual CPU time. When doing this synchronously as a test, it takes maybe half a second instead of 30 seconds.
2. The reason this is noticeable now is that for some reason, it lists all the build dirs. This is probably a bug in the new cmake importer, they should not be listed.

Fixing the second point would solve the problem, but fixing the first one somehow (just making it sync isn't a solution, but there is certainly a better way) would also be very nice since it will further speed up the import.
The first point is IMO the much worse bug, since that is what will cause large project imports (think clang) be very slow in either case. For completely no reason whatsoever.