Author Topic: debugger speed  (Read 13118 times)

Offline grv575

  • Official tester
  • Regular
  • ***
  • Posts: 381
debugger speed
« on: January 04, 2006, 06:46:30 am »
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).

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: debugger speed
« Reply #1 on: January 04, 2006, 05:26:18 pm »
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! :P
(After i finish revamping Codecompletion that is...  :mrgreen: )

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: debugger speed
« Reply #2 on: January 04, 2006, 05:34:15 pm »
Sometimes I regret the day when I said "Hey, why don't you use STL containers"  :lol: :lol: :lol:
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: debugger speed
« Reply #3 on: January 04, 2006, 05:49:15 pm »
Oh no! Please Rick, no! :lol:
I 'm still working on this plugin.
Be patient!
This bug will be fixed soon...

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1442
    • CenizaSOFT
Re: debugger speed
« Reply #4 on: January 04, 2006, 05:55:36 pm »
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.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: debugger speed
« Reply #5 on: January 04, 2006, 06:46:32 pm »
AH HAH! I KNEW IT! MUAHAHAHA It's the parsing of the ouptut!  8)

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

Code: [Select]
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: [Select]
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 :P
« Last Edit: January 04, 2006, 06:57:36 pm by rickg22 »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: debugger speed
« Reply #6 on: January 04, 2006, 07:00:27 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 :)

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 :)
Be patient!
This bug will be fixed soon...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: debugger speed
« Reply #7 on: January 04, 2006, 07:17:13 pm »
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 :)
« Last Edit: January 04, 2006, 07:24:16 pm by rickg22 »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: debugger speed
« Reply #8 on: January 04, 2006, 07:24:51 pm »
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 103 slower than allocating a wxArrayString and parsing a buffer?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: debugger speed
« Reply #9 on: January 04, 2006, 07:25:44 pm »
oops :P

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1442
    • CenizaSOFT
Re: debugger speed
« Reply #10 on: January 04, 2006, 07:34:56 pm »
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 :P

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: debugger speed
« Reply #11 on: January 04, 2006, 07:41:37 pm »
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...
Be patient!
This bug will be fixed soon...

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: debugger speed
« Reply #12 on: January 04, 2006, 07:52:52 pm »
Omg... I have to change my signature... :lol:
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: debugger speed
« Reply #13 on: January 04, 2006, 08:33:46 pm »
Yiannis: OK! :) I'll shut up now.
(I was just trying to help...  :oops: )

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: debugger speed
« Reply #14 on: January 04, 2006, 08:53:57 pm »
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).
 

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1442
    • CenizaSOFT
Re: debugger speed
« Reply #15 on: January 04, 2006, 09:07:12 pm »
Heh, that "website on STL" is the site of the STL implementation used by GCC :)

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: debugger speed
« Reply #16 on: January 04, 2006, 09:16:03 pm »
Heh, that "website on STL" is the site of the STL implementation used by GCC :)
To be honest, I was not aware of this :oops:. Anyway, I find it really helpful (especially when I was implementing a PriorityQueue (wrapper to a multimap) :)) with a lot of term definitions, examples, information and so on.

Michael

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1442
    • CenizaSOFT
Re: debugger speed
« Reply #17 on: January 04, 2006, 09:19:53 pm »
PriorityQueue... std::priority_queue<> didn't suit your needs? :)

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: debugger speed
« Reply #18 on: January 04, 2006, 09:37:57 pm »
PriorityQueue... std::priority_queue<> didn't suit your needs? :)
Unfortunately not :D. It was an exam for an advanced course in C++ meta-programming and distribute programming (one of the best course I have ever had, to be honest). The std::priority_queue<> did not fullfil the requirements (it would have been too easy :D). If I remember, indexes of the PriorityQueue were not unique. Therefore, I needed a multimap (with some modifications to fit the requirements). What it was very interesting and not so known was the problem related with elements of a same index :). Their order in the multimap is not fixed. SO, how e.g., would it possible to delete the older element if more than one element has the same index?

Michael

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: debugger speed
« Reply #19 on: January 04, 2006, 11:15:34 pm »
It is kind of useless for people talk about what they might think the bottlenecks in the code are and there solutions.  Someone should go and profile the debugger so we know where most of the actual time in the debugger is being spent.  Then we can start to talk about whether or not to use threads, or wxStringArrays, or Maps vs Vectors.  Or it might be that most of the time is just spent piping the stdin and stdout and there is nothing really to be done in speeding it up, but oops, there I go speculating.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: debugger speed
« Reply #20 on: January 04, 2006, 11:24:30 pm »
Good idea :)
Sorry for my over-enthusiastic attitude (see my sig.)

Offline grv575

  • Official tester
  • Regular
  • ***
  • Posts: 381
Re: debugger speed
« Reply #21 on: January 04, 2006, 11:39:27 pm »
grv575 you can't possibly compare the speed of C::B's debugger with Quincy's... You 're comparing apples with oranges here ;)

Well I'm an optimization freak  :D

But quincy does do watch variables as well and still has instant reponsiveness.  It may have to do with the fact that I'm running a 1.1 ghz centrino as well (tablet - why it's so slow), but the delay is bad enough that you're more inclined to use breakpoints and continue than stepping through 5-10 lines in a function.  Is the gdb verbose mode needed then, or what's it used for over the standard output gdb gives?

I remember the only thing quincy does is:
info f(rame)
every line.  Not sure exactly what for though - maybe to track which thread it is in or something.

IIRC gprof was a no go on the CB source.  Maybe I'll see if there's any good free assembly level call profilers that might be able to zero in on what's taking the most time on this machine.

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: debugger speed
« Reply #22 on: January 04, 2006, 11:52:00 pm »
IIRC gprof was a no go on the CB source.  Maybe I'll see if there's any good free assembly level call profilers that might be able to zero in on what's taking the most time on this machine.
Compuware's DevPartner Profiler Community Edition is a free and imho really good and powerfull profiler. However, it is a plugin for Visual Studio and I don't know if it is possible to get Code::Blocks compiled with MS Visual Studio and this profiler. But maybe I'll give it a try if I find some free time.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: debugger speed
« Reply #23 on: January 04, 2006, 11:58:47 pm »
grv: Is Quincy opensource? We might... *ahem* re-use *ahem* some of its code :lol:

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: debugger speed
« Reply #24 on: January 05, 2006, 12:36:52 am »
IIRC gprof was a no go on the CB source.  Maybe I'll see if there's any good free assembly level call profilers that might be able to zero in on what's taking the most time on this machine.

You have to enable profiling only for one target at a time, not globally in project. This happens because, unfortunately, you can't specify an output file when using -pg...
So, just enable profiling on the debugger plugin only and you got yourself some profiling info ;)

Note though, that I 'm not finished with the debugger plugin. It has some optimization opportunities but it's still early for it...
« Last Edit: January 05, 2006, 12:38:45 am by mandrav »
Be patient!
This bug will be fixed soon...

Offline grv575

  • Official tester
  • Regular
  • ***
  • Posts: 381
Re: debugger speed
« Reply #25 on: January 05, 2006, 01:08:28 am »
grv: Is Quincy opensource? We might... *ahem* re-use *ahem* some of its code :lol:

"Quincy is freeware open-source."
http://www.codecutter.net/tools/quincy/

The source is 300k.  Haven't looked at it yet though.  I do know it's using gdb 5.2.1 and not the newer 6.3 but still could be useful to salvage some of the source anyway.

Offline grv575

  • Official tester
  • Regular
  • ***
  • Posts: 381
Re: debugger speed
« Reply #26 on: January 05, 2006, 04:16:19 am »
Compiling the latest source and running through the debugger again, it looks like I may have been a little harsh about the speed.  It's actually perfectly usable (F7 stepping) on my machine.  Optimization of course isn't a bad thing - I think I'll still profile it just out of curiosity - but it's decent enough to not be unacceptably slow.  Guess I remembered it taking longer to move the carret in previous builds, but as it is it gives a decent speed impression.

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: debugger speed
« Reply #27 on: January 05, 2006, 08:24:17 am »
Compiling the latest source and running through the debugger again, it looks like I may have been a little harsh about the speed.  It's actually perfectly usable (F7 stepping) on my machine.  Optimization of course isn't a bad thing - I think I'll still profile it just out of curiosity - but it's decent enough to not be unacceptably slow.  Guess I remembered it taking longer to move the carret in previous builds, but as it is it gives a decent speed impression.


did you ever test an optimized ( by compiler switches ) build of CB ???  ( normal project file is for a debug build
and the update command only strips the output files, but no optimizations are done )

test this out (if you have another GB space left on your HD)  - you'll be astonished !

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1442
    • CenizaSOFT
Re: debugger speed
« Reply #28 on: January 05, 2006, 08:28:21 am »
My binary snapshots are already compiled with optimization flags, that would save him almost the whole GB :)

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: debugger speed
« Reply #29 on: January 05, 2006, 08:50:43 am »
My binary snapshots are already compiled with optimization flags, that would save him almost the whole GB :)

thanks Ceniza  -  now  I know how i can save a GB  :D