User forums > Help

Slow perfomance on linux (Ubuntu Dapper)

<< < (12/13) > >>

sque:

--- Quote from: Game_Ender on September 25, 2006, 05:34:48 am ---You are mistaken and probably thrown off by the fact that there is no listing for a "Live CD" for Dapper.  The standard "Desktop" CD is actually a live CD.

--- End quote ---

Bingo you were right. I had a beta cd of Dapper and wasn't live cd. the 6.06.1 is live cd too.
BUT! I am so embaresed :oops: I booted from the live cd and codeblocks works just fine :( It's time for me to format... (But all the other applications works exactly the same way).

I think i deserv all of you a "sorry", but after the format :P

thomas:

--- Quote from: sque on September 25, 2006, 01:16:13 am ---As for the TextWidth mystery... is it worth to look at? Should I try something?
--- End quote ---
If that's a known issue (which it is, apparently), it may be worth looking into wxFlatNotebook, too.
The reasoning behind this is that SciTE seems to work Ok for you, and wxFlatNoteBook is the most prominent difference between Code::Blocks and SciTE editors, so it might be worth having a look at that, too. In any case, it will be easier to fix than the many wxScintilla occurrences.

On my machine, wxPageContainerBase::OnPaint is called an entire six times whenever I do anything except typing with an editor. No idea why it happens, but 6 sounds like "5 times too often" to me. It may of course be an issue of the wxWidgets message queue, too (and as such may be different for you).
wxPageContainerBase::OnPaint calls GetTextExtent ( == TextWidth) twice every time (once on static text, and once on the tab title, both of which could as well go into a static variable). The same constants are recalculated over and over again in several places (when fitting to screen or scrolling). Normally, I'd say it doesn't matter, but if that function is really so slow, one might want to rethink this approach.

On my machine, the abysmal performance problem is not present, so I cannot verify whether all this matters at all.

sque:
After a clean fresh install of ubuntu (the previous has passed from many stages Brezy -> Dapper beta -> dapper final), there is a significant difference, CB is now workable, but occasionally I get the same wierd slowniness (for a few minutes).

Before formating, tried to eliminate some calls to the TextWidth, but when I tried to run CB (with the nvidia driver) my X crashed! With the "nv" driver it worked, and there was a good speed boost, but many artifacts. What I think but I it is difficult to implement as I am not familiar with the internals, the text's width should be cached in some way.

eranif:
six times? sounds alot.. I can look into it. Does it occures when you are moving the mouse over the tab drawing area? if so I think I know where the problem is.

However, the problem is occuring when typing in the editor, which according to your findings, is the only case where wxflatnotebook does not do excessive painting)

Not to mention, that I tested wxFlatnotebook with scintilla on Ubuntu and it works perfectly (the only time it does not, is when the TextWidth is called inside scintilla ... )

Still, I will have a look into the six drawing issue.
Btw, how did you measure it? did you add debug info? put a break point? etc.

Eran

thomas:

--- Quote from: eranif on September 26, 2006, 02:46:54 pm ---Does it occures when you are moving the mouse over the tab drawing area? if so I think I know where the problem is.
--- End quote ---
Not when moving, but when clicking on it, when giving back focus to a pane, when clicking onto an editor pane that already has the focus for the first time (does not happen the second time), when scrolling tabs, opening editors, etc.


--- Quote ---Btw, how did you measure it? did you add debug info? put a break point? etc.
--- End quote ---
Hahaha, too much trouble... I've simply put a printf("."); into that function and built Code::Blocks as console application. :)
What I get when anything "happens" to a tab is "......"

I came upon it at all because I did a global file search on GetTextExtent and found that it is indeed used in many places inside wxFNB (once inside a loop, too).

Just out of curiosity, I put in this printf into the draw function and saw that it was indeed called surprisingly often.
Since a tab's title is set via an accessor function, it should be trivial to do without all these and make the width a member function that is updated only when needed. GetTextExtent(_T("Tp"), ...) returns a constant so this could be trivially optimised out, too. I guess then it doesn't matter much how often a function is called any more.


BTW, similar things seem to happen inside Scintilla, for example it recalculates the line number width each time is is drawn (which leads to the question: Does turning line numbers off improve performance?), and it recalculates the font's (constant) ascent value when showing tooltips each time, too. Tooltips aren't shown a hundred times per second, but if it can take hundreds of milliseconds for GetTextExtent to finish, it may be worthwile to cache this too...
Unluckily, global search following the many alias functions inside wxScintilla reveals that it recalculates a lot of text widths in many places (above all, formatting text... :(), so rather than fixing one or two hotspots, the only feasible way of fixing things may be to find a GetTextExtent replacement.

I don't know how it is exactly implemented, however from the documentation, it almost looks like cairo_scaled_font_text_extents() is really the same as cairo_show_text(), except for suppressing the actual output.
As a proposed solution, one could call cairo_scaled_font_glyph_extents() once (once every time the editor font is changed), and on request sum up the x_advance values of all characters in a string (using x_bearing for the last character). Summing up one or two dozen doubles from an array should not take any significant amount of time at all.
Anyone here have a deep insight into Cairo and willing to give it a shot? ;)

Navigation

[0] Message Index

[#] Next page

[*] Previous page