Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

debugger speed

<< < (2/6) > >>

rickg22:
AH HAH! I KNEW IT! MUAHAHAHA It's the parsing of the ouptut!  8)

Look at this: (RC2, i'm at work :mrgreen: )


--- Code: ---for (unsigned int i = 0; i < lines.GetCount(); ++i)
{
...
if (lines[i].StartsWith( ...
else if (lines[i].StartsWith( ...
else if (lines[i].StartsWith( ...
...
else if (lines[i].StartsWith(g_EscapeChars)) // ->->
            wxRegEx reSource;
  reSource.Compile(...
}

--- End code ---
There's a regex compilation inside a tight for-loop (I agree, it's conditional, but nevertheless it'll be done once per output-parsing). If you make it a member and init it on the constructor, it'll run much faster :)

Edit: You can also get rid of the

--- Code: ---wxArrayString lines = GetArrayFromString(buffer, _T('\n'));

--- End code ---
by scanning for newlines manually and extracting the string one at a time. This spares us a lot of memory allocation.

Edit again: Of course, if this code was optimized previously on SVN, scratch all that :P

mandrav:

--- Quote from: rickg22 on January 04, 2006, 06:46:32 pm ---There's a regex compilation inside a tight for-loop (I agree, it's conditional, but nevertheless it'll be done once per output-parsing). If you make it a member and init it on the constructor, it'll run much faster :)

--- End quote ---

I know Rick :)
I said I 'm still working on it. But don't expect this to speed things up because most of those conditionals happen once or twice a second (approximately).

Since we 're on the subject:

grv575 you can't possibly compare the speed of C::B's debugger with Quincy's... You 're comparing apples with oranges here ;)
C::B will display a whole slew of information in every debugging step. Granted, this will take some longer but not that much. Actually the only time I saw it slow down was when I was watching a '*this' which had a whole *lot* of members (STL, etc). If you take a look at the debugger's debug log, you will see what kind of information it parses in each debugging step.
And working with gdb using annotations (--annotate) won't make it run faster (we used to use this approach). It's just that there is too much information to update...
On the other hand, when debugging MSVC executables with CDB, it's not that slow. You know why? Because CDB doesn't expand nested types so less info comes in...

Just a few pointers.
Suggestions are always welcome of course :)

rickg22:
Yiannis: I'm having a Deja Vu. While doing the codecompletion optimization i noticed that i could (haven't done it yet, but will) build a tree structure using maps (inside the parserthread), to mimic the structure used inside the wxTreeCtrl. Using STL maps will make the items get sorted automatically. Finally, I'll trigger an event to update the tree (no need for sorting now) using the temporary structure.

My question is: Why not do it the same way for the debugger? Using a "debuggerthread" (TM) to build the debug tree? This will also give us an advantage: If at any point you're not finished building the tree, and the user press shift-f7 again, you can just clear the temporary tree structure, and abort the rendering, for when the user finally stops.

The trick is having a container (not STL container, just a container object) to hold all the debugger-related structure. Everytime you access the container, you enter a critical section, and voila :)

Edit: No need to have this done by tomorrow, just finish polishing the new UI and notebook :)

thomas:

--- Quote from: rickg22 on January 04, 2006, 07:17:13 pm ---Everytime you access the container, you enter a critical section, and voila :)
--- End quote ---
You realize that entering and leaving a critical section is on the order of 103 slower than allocating a wxArrayString and parsing a buffer?

rickg22:
oops :P

Navigation

[0] Message Index

[#] Next page

[*] Previous page