Slow perfomance on linux (Ubuntu Dapper)

[sque]

Hi!
1st of all, REALLY Ty for this great IDE, although it is still under development it is a much promising project and it is something that was missing from the free community

My main prob is that code::Blocks works slow on linux (the widgets rendering part). I have compared the same version 1.0RC2 on windows and the speed is uncomparable.
More specificly the scroll inside the editor (and on th project browser) is jerky -laggy. Also If I start typing something my cpu pops to 100% (this may be code completetion related but it may be rendering prob again).
Another example is that if I change virtual desktop and return to the one that Code::Blocks is opened, the window of Code::Blocks  takes about 1 sec to rerender every part of it. I know that the values (of time) that I am complaining are quite low, but why on Windows is so much faster?

I tried the latest build too (11 april) and same results.

Notice: Similar behaviour had Firefox on my machine (It is an ubuntu package bug of firefox) and I fixed it by setting a enviroment value to disable firefox to use Pango. I am just saying it in case that maybe a similar bug(?).

I hope to see it fixed sometime, till then I will keep up my work on Code::Blocks as it semi-rocks (code completition must be finished )

[takeshimiya]

Can you confirm the 100% cpu thing happens also with other Scintilla based text editors? (ie. SciTE, wyoEditor, Anjuta, etc).

About slow rendering, GTK2 is not fast, not at least by default.
You can disable pango rendering as you've done with Firefox, but expect to loose text antialiasing and internationalization.
But the truth is that Scintilla without pango is so much faster, so it's your choice: fast or nice.

[cyberkoa]

I was using Ubuntu Breezy 5.10 a few days ago with the latest SVN (at that time) , very smooth and very unlikely encounter bug (though sometime will hang the session, need to switch to console to end)

could it because Dapper is still not stable yet ?

[sque]

Can you confirm the 100% cpu thing happens also with other Scintilla based text editors? (ie. SciTE, wyoEditor, Anjuta, etc).

I installed SciTE and tryied writting quickly many many words at many highlitting modes. The biggest cpu usage was 30-40%. I also tried the same at gedit, same results.

At Code::Blocks with a slow rate of typings it gets 100%. I am not a very fast writter, but the lag is noticable. Offcourse this doesn't make code::blocks unusable but It's annoying!

[sque]

I was using Ubuntu Breezy 5.10 a few days ago with the latest SVN (at that time) , very smooth and very unlikely encounter bug (though sometime will hang the session, need to switch to console to end)

could it because Dapper is still not stable yet ?

I was using breezy too before a couple of days and I had the same prob. Maybe its an ubuntu related thing...

btw, I dont compile source of code::blocks, I use the .deb that you give for ubuntu distros.

[takeshimiya]

AFAIK it's not ubuntu related.
I've seen a lot of reports about the 100% CPU C::B in linux bug while editing text.

Can you confirm it still happens with CodeCompletion plugin disabled?

[sque]

Can you confirm it still happens with CodeCompletion plugin disabled?

Almost the same results, I think, without CodeComplation, the cpu usage graph is a bit different.
I attach 2 screenshoots of the cpu usage graph.
1. With CodeCompletition
2. Without CodeCompletition

[attachment deleted by admin]

[takeshimiya]

What's with the small-sized graphs?

This is a time where a profiler will be highly appreciated.

[sque]

What's with the small-sized graphs?

Its screenshoots from the system monitor applet of gnome :oops:
I thought you would ask to test with a profiler... but my expertise on this is limited. Anyway I promise I 'll try it later, lesson time!

[takeshimiya]

I thought you would ask to test with a profiler... but my expertise on this is limited. Anyway I promise I 'll try it later, lesson time!

No problem, can wait.
I personally can't reproduce the bug, but I hear frequently about it.

[Michael]

I was using Ubuntu Breezy 5.10 a few days ago with the latest SVN (at that time) , very smooth and very unlikely encounter bug (though sometime will hang the session, need to switch to console to end)

could it because Dapper is still not stable yet ?

I was using breezy too before a couple of days and I had the same prob. Maybe its an ubuntu related thing...

btw, I dont compile source of code::blocks, I use the .deb that you give for ubuntu distros.

Hello,

.deb package are compiled under ubuntu 5.10 with standard ubuntu packages. Anyway, it could be interesting to try building C::B from SVN sources on Dapper (which AFAIK is stable, but needs some polish and see if C::B is still slow.

Personally, I have not remarked this issue. Well, my desktop is old (PIII 500 MHz), but C::B works (scrolling, rendering, etc.) similar to many other applications.

Best wishes,
Michael

[thomas]

Recently, I observed that a perverse amount of update_ui events are being sent around and postulated that this might possibly be one of the reasons for poor performance on some systems.

My problem is that I cannot reproduce the 100% load problem, so it is kind of hard to find out

However, this still looks promising:
When moving the mouse anywhere inside the Code::Blocks window (editor, manager pane, menu bar), I get a CPU usage of about 25% (averaged over a 1-minute interval). Removing a couple of EVT_UPDATE_UI entries reduces the CPU load to 12% on the same machine.

Now, I would like those having the 100% CPU problem to assist in confirming (or not confirming) that this may be a reason for your poor performance:
Edit src/main.cpp, plugins/compilergcc/compilergcc.cpp, and plugins/debuggergdb/debuggergdb.cpp, removing all lines containing EVT_UPDATE_UI.
Recompile Code::Blocks and see if the CPU load is still that high.

Note that you cannot actually use this modified version for normal development, as it does not properly update quite a few things any more! The purpose is just to verify whether this is where your CPU time goes.

[Michael]

Now, I would like those having the 100% CPU problem to assist in confirming (or not confirming) that this may be a reason for your poor performance:
Edit src/main.cpp, plugins/compilergcc/compilergcc.cpp, and plugins/debuggergdb/debuggergdb.cpp, removing all lines containing EVT_UPDATE_UI.
Recompile Code::Blocks and see if the CPU load is still that high.

Hello,

If you temporary commit the changes (alternatively, I can also apllied the change locally , I can build a .deb package and make it available on my File Hosting for those using Ubuntu.

Best wishes,
Michael

[thomas]

Uh... I cannot possibly commit that  :shock:
With these event table entries removed, none of the menus will be properly updated, the application will be utterly unusable. 

It is really easy to do the modifications locally, though. Just search for EVT_UPDATE_UI in those 3 files, or do a global search.
The EVT_UPDATE_UIs are all grouped in one large bunch, so you only need to select 10-20 lines and press Ctrl-Shift-C every time
I did not upload a patch because it is so trivial really.

[Michael]

Uh... I cannot possibly commit that  :shock:
With these event table entries removed, none of the menus will be properly updated, the application will be utterly unusable. 

Yes, you are right. It will make more problems than anything else.

It is really easy to do the modifications locally, though. Just search for EVT_UPDATE_UI in those 3 files, or do a global search.
The EVT_UPDATE_UIs are all grouped in one large bunch, so you only need to select 10-20 lines and press Ctrl-Shift-C every time
I did not upload a patch because it is so trivial really.

Ok, I will modifiy them now, build and upload in 2-3 hours (for the .deb package at least 90-120 minutes are necessary).

Best wishes,
Michael