User forums > Help
Slow perfomance on linux (Ubuntu Dapper)
sque:
--- Quote from: sethjackson on August 30, 2006, 03:29:37 am ---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....
--- End quote ---
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%)
--- Quote from: Game_Ender on August 29, 2006, 11:59:21 pm ---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.
--- End quote ---
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
);
}
--- End code ---
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)
--- End code ---
* 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)
--- End code ---
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 :D), 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 :D
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 :P 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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version