Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

Codecompletion delays fixed in rev 1826 (update: in rev 1840)

<< < (7/9) > >>

rickg22:
"One extra thread" the answer is. More refinement Code completion needs, indeed. Hmm.

Ceniza:
I wonder if setting CodeCompletion to use only 1 thread would "help". It's like if instead of using 2 threads it was using 1/2 thread.

thomas:

--- Quote from: Game_Ender on January 25, 2006, 01:21:07 am ---As for this I have one question, why are we using threads at all if doesn't run more than one at once?
--- End quote ---
It does not freeze the GUI for 20 seconds.


--- Quote ---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?
--- End quote ---
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.


--- Quote ---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.
--- End quote ---
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.


--- Quote ---Also I think the threading model needs a thorough rewrite or going over because it dead locks all the time on linux.
--- End quote ---
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.

Ceniza:
I tried revision 1854 last night which creates 4 threads and I have the same results :(

BTW, those times (working then stalled) are about 3-5 seconds each (haven't timed them though, but they really count in seconds). Doesn't look like waiting for I/O to me.

thomas:
Uh... seconds? What on earth is taking seconds? (I was thinking you had the task monitor running at higher speed... :lol:)

Rick, you don't happen to trigger the next parser with a wxTimer event, do you?

Navigation

[0] Message Index

[#] Next page

[*] Previous page