debugger speed

[grv575]

Could the debugger speed of CB be improved?  Other ide's which rely on gdb as a backend seem to fare much better in terms of the time it takes from the moment you hit the step button to the time the arrow updates.  For example

http://www.codecutter.net/tools/quincy/

is really fast.  You can hit the step button over and over and it updates without unnerving slowness.  One of the differences is that it seems to use a less verbose gdb mode which might account for some of the sluggishness of the CB debugger, although I'd wager that profiling the gdb/debugger handling code would also have a great impact.

So, is this an area that can be improved, as it's a shame that it's so slow compared to other gdb backend ides (which are much less polished).

[rickg22]

grv: Depends. Tell me if  there's any array scan in the debugger plugin, and i'll take out my STL swiss-army-knife in no time!
(After i finish revamping Codecompletion that is...  :mrgreen: )

[thomas]

Sometimes I regret the day when I said "Hey, why don't you use STL containers"  :lol: :lol: :lol:

[mandrav]

Oh no! Please Rick, no! :lol:
I 'm still working on this plugin.

[Ceniza]

C'mon thomas, you just showed Rick the light, it's not your fault if he goes blind

No need to reply to this message.

[rickg22]

AH HAH! I KNEW IT! MUAHAHAHA It's the parsing of the ouptut! 

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(...
}

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'));

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

[mandrav]

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

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]

Everytime you access the container, you enter a critical section, and voila

You realize that entering and leaving a critical section is on the order of 10³ slower than allocating a wxArrayString and parsing a buffer?

[rickg22]

oops

[Ceniza]

Rick: Advice from a book (not textually): "Many times having a structure that sorts its elements in every insertion (like set and map) is slower than just inserting all the elements and sorting them at the end (in a vector, deque or list)."

I haven't tried it myself, but I'll maybe do

Also remember there're algorithms to search an element in a sorted range.

You've been a bit paranoiac about optimizations (that's good too) so I'm just throwing some more wood to the fire

[mandrav]

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.
<snip>

Here we go again
Rick, you 're forgetting one thing: communication with the debugger is done by piping input-output channels. This is inherently slow, when compared with directly calling code and receiving results (like codecompletion).
*And* you can't stop the debugger once you 've given it a command. You *must* wait to get all its output...

[thomas]

Omg... I have to change my signature... :lol:

[rickg22]

Yiannis: OK! I'll shut up now.
(I was just trying to help...  :oops: )

[Michael]

Rick: Advice from a book (not textually): "Many times having a structure that sorts its elements in every insertion (like set and map) is slower than just inserting all the elements and sorting them at the end (in a vector, deque or list)."

IMHO, it depends on your application. Insertion is slower in a map, but faster in a vector. Find is slower in a vector, but faster in a map. All this remember me database's indexes . Do a lot of insert into a map is time consuming and I think as Ceniza's book that in a such a case, it would be better to insert the elements at end of the container and sorting them later. Anyway, sorting algorithms are slow (especially with a lot of elements).

Personally, I find this website on STL useful .

Michael

PS.: Optimization is a highly discussed topic. Useful? Not useful? When? IMHO an "intelligent" optimization is ok (especially if done at the end).