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(...
}
wxArrayString lines = GetArrayFromString(buffer, _T('\n'));
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 :)
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?
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>
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)."
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.
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?
grv575 you can't possibly compare the speed of C::B's debugger with Quincy's... You 're comparing apples with oranges here ;)
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.
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.
grv: Is Quincy opensource? We might... *ahem* re-use *ahem* some of its code :lol:
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.
My binary snapshots are already compiled with optimization flags, that would save him almost the whole GB :)