Slow editing in Ubuntu Feisty

[Sastraxi]

Hi,
The nightly builds have been too slow for my system which is otherwise pretty decent in the performance arena.
It's an Athlon XP 2500+ with a Geforce 6600, and 1 gb of RAM. I can play games and such fine. But scrolling is
just painfully slow, and typing is very slow as well. I'll provide more details, but I don't know what to suggest.

I'm currently running the VERY latest nightly.

The problem persists with different window managers (I use beryl, mostly).
Cam

[Deschamps]

I'm sorry because i can't help you. But, IMHO, it's probably something wrong in your box setup, because i'm running an up-to-date C::B (compiled from svn sources against wxGTK-2.8.4) with an AMD Athlon XP 1800+, 1GB RAM, nVidia Geforce3 (propietary rev.8776 drivers) and openSUSE 10.2 (GNOME 2.16.1), and all is running relatively fine (i've enabled all the core and contrib plugins and the default configuration -e.g. code completion, et al-).

How much processes are you running simultaneously when executing C::B?

Edit: more detailed enviroment.

[Alturin]

Hi,
The nightly builds have been too slow for my system which is otherwise pretty decent in the performance arena.
It's an Athlon XP 2500+ with a Geforce 6600, and 1 gb of RAM. I can play games and such fine. But scrolling is
just painfully slow, and typing is very slow as well. I'll provide more details, but I don't know what to suggest.

I'm currently running the VERY latest nightly.

The problem persists with different window managers (I use beryl, mostly).
Cam

Try disabling all plugins and see if it is still so slow; if it is you can be pretty sure it's something on your side (without the plugins C::B is pretty much "just an editor").

[rjmyst3]

There have been many people posting builds for Ubuntu lately. Make sure the build that you use is linked with wxGTK 2.8.4, all other versions of wxGTK are buggy.

The only build that I can personally vouch for is cstudent's. That will be the .deb link in the very first post in each nightly build thread.

[Sastraxi]

Thanks for your replies.

Deschamps:
top gives me 144 tasks running, with all but 2 sleeping. I can reproduce this with having nothing but codeblocks open (but Gnome's panel and all that is still running). CPU is about 2.0% used, with it spiking up to 10% when I'm typing this in Firefox.

rjmyst3:
I have added the wxWidgets repository and am using 2.8.4 (note that the problem occurred also when the builds were linked to 2.6.x), and the package I am using is indeed the deb file from the first post in the nightly build thread.

Alturin:
I am unhappy to report that even upon disabling every plugin, saving the "default" thing and reloading it, the responsiveness is identically sub-par.

Oh, and I should note that I'm using the 9631 drivers, and Gnome 2.18.1.

[dmoore]

this *could* be a wxscintilla related problem. each time wxscintilla needs to redraw it fires a wxWakeUpIdle, which by default sends message to all application windows (C::B has lots of windows).

If this is the problem, the fix seems relatively easy. In the wxWidgets Manual (http://www.wxwidgets.org/manuals/stable/wx_wxidleevent.html#wxidleeventsetmode) :

By default, idle events are sent to all windows (and also wxApp, as usual). If this is causing a significant overhead in your application, you can call wxIdleEvent::SetMode with the value wxIDLE_PROCESS_SPECIFIED, and set the wxWS_EX_PROCESS_IDLE extra window style for every window which should receive idle events.

someone just needs to go through the handful of instances in the code where Idle events are processed and set the window style and then put a call to the static function SetMode somewhere in the startup code...

[thomas]

From looking at it for 3 minutes, adding wxIdleEvent::SetMode(wxIDLE_PROCESS_SPECIFIED); to the application under Windows seems to have no visible side effect. Everything seems as before.

It thus seems that whatever uses idle events already requests them properly and we might just try and add that line without any other modifications, and see if it fixes anything for Linux.

[dmoore]

Thomas: unfortunately I don't think the windows do set the extended style properly (not even wxscintilla). the only side effect may be slow updates because OnIdle handlers don't get called often enough. Just in case, I've put up a patch to add the window style in as many places as I could find including wxPropGrid and wxScintilla (I haven't touched the contrib plugins). I had to comment many of the SetExtraStyle calls out because many of the classes in question were derived from wxEvtHandler and not wxWindow - I've left the commented lines in the patch - not sure if wxWidgets will send the onIdle message to non-wxWinodw EvtHandlers...

patch: http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2048&group_id=5358

In any case, spawning idle events with wxWakeUpIdle seems like a very unstable way to call data/gui refresh methods because wxWakeUpIdle appears to tell everything in the app that it is now an idle time not just the parent/child event handlers of the caller. Maybe we need to file a bug with wxScintilla maintainers?

it didn't appear to break anything on windows (didn't test any contrib plugins, but did try debug and build). As I don't have access to a linux machine right now can someone on linux test to see if there's any improvement? In the past I have noticed lagginess while scrolling through text on my Ubuntu Feisty machine.

[dmoore]

hi again. i deleted a couple of my posts on this thread because I had deluded myself that this patch was the answer . (I've updated the patch a few times as well). I doubt that my patch will solve the problem on Linux - other gui elements such as wxAUI may be partially to blame.