Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: rickg22 on August 03, 2005, 05:30:18 pm

Title: Regarding parser optimization
Post by: rickg22 on August 03, 2005, 05:30:18 pm
(This topic was split)

It said "too many '..' .

Yes, the parser needs a HEAVY optimization, I don't like it at all. First, it uses events to trigger the opening of new files, slowing everything down. Second, to avoid the slow down, they use recursive wxYield's, which may cause crashes once in a while, depending on the circumstances. All of this because of the use of multiple threads.

When 1.0-final is finished, I'm revamping the whole thing. At least the thread handling, the parsing itself gives me a headache just by reading it. (everything's hardwired! :? )
Title: Re: Converting Torque Game Engine VC7 projects to CodeBlocks
Post by: grv575 on August 08, 2005, 09:34:18 am
There's no real advantage to more than 1 UI input thread and 1 worker thread (unless you're doing lots of SMP processing).  The synchronization code is just a lot of unneeded overhead for a GUI like this if it's spawning lots of threads like that.
Title: Re: Converting Torque Game Engine VC7 projects to CodeBlocks
Post by: rickg22 on August 08, 2005, 08:34:56 pm
You're right... we should set the # of maximum threads to ONE. However, what happens if we hit an #include in the middle of a parse?

Hmmm....
Title: Re: Converting Torque Game Engine VC7 projects to CodeBlocks
Post by: grv575 on August 09, 2005, 06:42:07 am
Well one thread (the main thread) should be responsible for GUI input so that the user doesn't have to wait for something in order to click a button.  Then a second worker thread should do all the editor parsing in the background.  There no point in having this worker thread spawn more threads when it hits an include...just have it include the file itself.  The user is not waiting on the parser anyway...the main thread lets them input while the parsing is going on in the background.

Using > 1 thread for the background thread only makes sense if a) you know there will be > 1 cpu on the machine (or dual core chip) and b) there is enough processing to keep both thread fully busy.  If either a) or b) is not true then > 1 background thread is just a waste of resources and actually slower.  Plus the thread synchronization then is just extra unneeded overhead (and mutexes, which are portable as opposed critical sections which are local and not portable to unix, are slow).

What I'm trying to say is you gain nothing and lose a lot by making the background parsing asynchronous...
Title: Re: Converting Torque Game Engine VC7 projects to CodeBlocks
Post by: rickg22 on August 09, 2005, 07:40:54 am
Yes, I know. However, I'm not the one who took that decision... but I'll find a way to fix it.