Author Topic: Regarding parser optimization  (Read 6779 times)

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Regarding parser optimization
« 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! :? )
« Last Edit: August 09, 2005, 07:44:04 am by rickg22 »

grv575

  • Guest
Re: Converting Torque Game Engine VC7 projects to CodeBlocks
« Reply #1 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.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Converting Torque Game Engine VC7 projects to CodeBlocks
« Reply #2 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....

grv575

  • Guest
Re: Converting Torque Game Engine VC7 projects to CodeBlocks
« Reply #3 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...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Converting Torque Game Engine VC7 projects to CodeBlocks
« Reply #4 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.