Slow perfomance on linux (Ubuntu Dapper)

[sque]

Has anyone tried SciTE on a *nix box, and compared it to C::B on the same *nix box?
I may try to compile Scintilla and SciTE soon to see if it is slow....

I tried Scite and there are no problems like this. Typing-displaying character is instant, cpu-usage is low, scrolling etc are also acting normally. The only slowiness I saw on scite is when I tried to paste 1000 lines of C++ code from codeblocks to scite it took 5 seconds for scite to become responsible (and cpu usage went 100%)

Sque, I suggest you just give sysprof a try its not to hard to figure out how it works and would probably a good learning experience.  Sysprof shows you a tree view of each running process and how much of its time was spent in each branch (each branch being a function with its subbranches being the functions it calls).  You have to find the one which is codeblocks and go from there.

I already gave a try on Sysprof and as you can see on previous posts there are attachments of its log. What I can't understand is what kind of value is the number that displays. Time? calls? . If I assume that this is some type of time It seems that there is an abuse from libgdk-x11..., libpango and libcairo with libpango getting the leadership (4.12 self) after that libcairo. Inside codeblocks the only thing that takes time is DoPaint. So the problem is from DoPaint and child calls.

So! I made some changes on codeblocks source on the ScintillaWX::DoPaint to get some times

Code

void ScintillaWX::DoPaint(wxDC* dc, wxRect rect) {
    paintc++;
    clock_t startClock, endClock ;
	struct timeval now, start;

	// Start timers
	startClock = clock();
	gettimeofday(&start, NULL);



    printf("DoPaint(%d)",paintc);
    paintState = painting;
    Surface* surfaceWindow = Surface::Allocate();
    surfaceWindow->Init(dc, wMain.GetID());
    rcPaint = PRectangleFromwxRect(rect);
    PRectangle rcClient = GetClientRectangle();
    paintingAllText = rcPaint.Contains(rcClient);

    dc->BeginDrawing();
    ClipChildren(*dc, rcPaint);
    Paint(surfaceWindow, rcPaint);

    delete surfaceWindow;
    if (paintState == paintAbandoned) {
        // Painting area was insufficient to cover new styling or brace
        // highlight positions
        FullPaint();
    }
    paintState = notPainting;
    dc->EndDrawing();

    endClock = clock();
	gettimeofday(&now, NULL);
    printf("Time:CPU(%5.3f ms), REAL(%5.3f)\n",
        ((float)(endClock-startClock) / ((float)CLOCKS_PER_SEC/1000.0)),
        (float)((float)now.tv_sec-start.tv_sec)*1000.0+((float)now.tv_usec-start.tv_usec)/1000.0
        );
}

Here is the output on the console when
  * Tapping the right arrow 5 times to move at a new location
   

Code

DoPaint(1724)Time:CPU(120.000 ms), REAL(232.222)
DoPaint(1725)Time:CPU(0.000 ms), REAL(4.103)
DoPaint(1726)Time:CPU(110.000 ms), REAL(217.649)
DoPaint(1727)Time:CPU(0.000 ms), REAL(4.151)
DoPaint(1728)Time:CPU(100.000 ms), REAL(243.462)
DoPaint(1729)Time:CPU(0.000 ms), REAL(8.608)
DoPaint(1730)Time:CPU(100.000 ms), REAL(228.856)
DoPaint(1731)Time:CPU(0.000 ms), REAL(3.834)
DoPaint(1732)Time:CPU(150.000 ms), REAL(285.846)

   * Writting the word: "12345" veryyy fast (in less than a second)

Code

DoPaint(1872)Time:CPU(0.000 ms), REAL(2.006)
DoPaint(1873)Time:CPU(120.000 ms), REAL(193.427)
DoPaint(1874)Time:CPU(0.000 ms), REAL(2.551)
DoPaint(1875)Time:CPU(90.000 ms), REAL(185.037)
DoPaint(1876)Time:CPU(0.000 ms), REAL(2.171)
DoPaint(1877)Time:CPU(90.000 ms), REAL(205.687)
DoPaint(1878)Time:CPU(0.000 ms), REAL(2.036)
DoPaint(1879)Time:CPU(100.000 ms), REAL(189.700)
DoPaint(1880)Time:CPU(0.000 ms), REAL(12.403)
DoPaint(1881)Time:CPU(90.000 ms), REAL(191.264)

     So it needs about 193+185+205+189+191=963 ms to render it which is maybe more than I tried to type it

The wierd (at least for me) is that CPU times are greatly different than the real times. What I suspect is that the problem is on somekind of mutexs that consum time to lock-unlock. I checked on the sysprof log and the only mutexes that I found are inside libcairo. But... why only on some kind of PCs?

[eranif]

Hi,
Did anyone come up with any solution for this problem?

I having the same problem on fedora core 4 & 5

Unistalled them, installed Ubuntu Dapper (which I seem to like more then FC ), problem still there.

The only different is that I am having the problem with my demo application that I wrote for the CodeCompletion alternative (which uses scintilla).
The typing is *very* slow, if you type more than 5 chars, the cursor disappear ... for a second or two  :lol:
Holding the enter key down, will "freeze" the application until you leave it and then it will insert all the newlines.

I downloaded SciTE, built it, ran it - works perfect.

Any suggestions?
Maybe it is related to my processor which is 64bit?
or my video card ATI?

Eran

[sque]

Plz some focus on this problem... some ideas, some suggestions, Ask for any test.
YOU ARE GOING AGAINST OUR RIGHT TO WORK WITH C::B

Ok, I just want to say that I am using ubuntu, I have no other problem (maybe I found my best linux distro), and because of C::B some small ideas of reinstalling gentoo pop-up in my head (and I DONT want!). I am working on a project and every day that a new file comes, more lines appear, the problem grows and grows. Believe it getting in your nervs when you want to scroll up or down to see what it is written and you think it twice before doing this.

So, what I ask, is some focus on this problem. Although I understand that you have no idea why on the hell this happens and you cannot reproduce it, we (as I see, I am not only one) can give you plenty of info of our system or whatever you want, we can make (almost)any test. If It could be possible, I would sent you my box for examination/experiments  But I wouldn't say no for a VNC connection to make whatever tests you want. I think it is a critical BUG, it makes C::B totaly unusable!

[Game_Ender]

I seem to have the problem on and off.  It was problem for me in the past but not so much now (possible driver issue?).  Eranif can you post you exact system specs and the result of the "glxinfo" command?  CB definitely seems faster when I have the fglrx driver installed vs. the standard open source ATI one.  I run 32 bit Ubuntu.

sque, if the bug is affecting you so much I suggest you grab an Ubuntu live CD, and a precompiled version of codeblocks that has the issue and try it on as many computers as you can.  Maybe you can find some kind of hardware + software that causes the issue.

[eranif]

I forgot to post it, but I already solved my problem. My problem was excessive calling to TextWidth() function which caused huge performance degradation.
 
This slowed the typing in the editor only Linux machines ( I tried it on FC4/5 and Ubuntu) but did not cause any slow effects on windows.

This was called on OnChange notification

Eran

[Pecan]

I forgot to post it, but I already solved my problem. My problem was excessive calling to TextWidth() function which caused huge performance degradation.
 
This slowed the typing in the editor only Linux machines ( I tried it on FC4/5 and Ubuntu) but did not cause any slow effects on windows.

This was called on OnChange notification

Eran

Where, what Onchange. What TextWidth()? Scintilla, Main, SDK, what Line?

[eranif]

I forgot to post it, but I already solved my problem. My problem was excessive calling to TextWidth() function which caused huge performance degradation.
 
This slowed the typing in the editor only Linux machines ( I tried it on FC4/5 and Ubuntu) but did not cause any slow effects on windows.

This was called on OnChange notification

Eran

Where, what Onchange. What TextWidth()? Scintilla, Main, SDK, what Line?

Hi,

On my first post, I complained of having similar problem (of very slow performance) on linux using other application that uses scintilla.

the problematic function, was a function named TextWidth(), which is a wrapper for wxDC::GetTextExtent.

This function, uses *alot* of CPU on Linux (and is hardly noticed on windows), and it was called alot on my application.

Once this function is removed from my application code, the problem was gone.
I wonder whether this function is the cause of the other problem.
Eran

[troels]

This function, uses *alot* of CPU on Linux (and is hardly noticed on windows), and it was called alot on my application.

Probably related to this:
http://article.gmane.org/gmane.comp.lib.wxwidgets.devel/77308

[sque]

sque, if the bug is affecting you so much I suggest you grab an Ubuntu live CD, and a precompiled version of codeblocks that has the issue and try it on as many computers as you can.  Maybe you can find some kind of hardware + software that causes the issue.

First of all the versions that I have tested (the last 6 months) had the same prob. Never tried the RC2
Otherwise I would stick with a working one, and I wouldn't whining

That was a good idea with live cd, I go forward to download one (But only breezy ubuntu comes in a live cd). Anyway, I ll come with more results.

As for the TextWidth mystery... is it worth to look at? Should I try something?

[Game_Ender]

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.

[sque]

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.

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

[thomas]

As for the TextWidth mystery... is it worth to look at? Should I try something?

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]

Does it occures when you are moving the mouse over the tab drawing area? if so I think I know where the problem is.

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.

Btw, how did you measure it? did you add debug info? put a break point? etc.

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?