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

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

<< < (8/9) > >>

Ceniza:
By checking the process' threads you can see all of them are executed in the working time (I got 36 threads with Thomas' workspace: 9 projects, 4 threads per project). When the CPU is stalled... well... you know... they do nothing.

rickg22:

--- Quote from: thomas on January 25, 2006, 11:36:21 am ---Rick, you don't happen to trigger the next parser with a wxTimer event, do you?

--- End quote ---

Nope... this is how it works: The wxTimer works as a "countdown for start parsing." When a new file is requested to be parsed (from the main thread, that is), it resets the countdown. When all files are requested, the countdown begins and finally the parsing is triggered. This is to avoid problems with adding files recursively taking forever.

But I think the part that measures the time is broken :P I was going to change it, but i was too tired last night.

But don't worry! Everytime we're getting closer to a bug free plugin :)

Ceniza:
Rick: could you add the textbox for the concurrent threads again? I'd like to try it with only 1 thread.

rickg22:
Um... :oops: I don't know how... I didn't touch that code :P

Ceniza:
I'm trying the latest changes in CodeCompletion and the results are very similar: 50% working time and about 60-75% CPU usage (when working).

Even better, Code::Blocks just died with a "Reading from 00000000" error.

Revision 1889.

Navigation

[0] Message Index

[#] Next page

[*] Previous page