As for this I have one question, why are we using threads at all if doesn't run more than one at once?
It does not freeze the GUI for 20 seconds.
I think you mean it only runs one <i>extra</i> thread, counting the main thread if you have one CPU?, or it only one thread total include the main one?
The former is the case (obviously, nothing else makes sense).
You could indeed argue why the "thread pool" is rather a "thread blocker" than a real thread pool, but that is not the cause of the bottlenecks in parsing. Rick initially wrote that code to be simple, and he is certainly aware of the unnecessary thread creation overhead. That, however, is not the thing which causes all the problems which we are facing in code completion. Since we are only creating a dozen or two unnecessary threads, this is manageable, even on such a bad performer like Windows. He might change that one day, but only after the
real issues are solved.
The whole point of threads is to run more than the number of processors you have because the CPU is rarely full on, threads of execution spend quite a bit of time waiting.
Look at Ceniza's screenshot. It has a higher resolution than mine, so the issue is better visible there.
His CPU is 75% idle on the average (if you count in hyperthreading). 50% of the time, it uses one CPU, and 50% of the time, it is completely stalled. Thus, he could as well run two more concurrent threads without any penalites.
Also I think the threading model needs a thorough rewrite or going over because it dead locks all the time on linux.
Yes, although the deadlocks do not necessarily come from that, the parser does some heavy locking here and there too, so it might as well be that.
