Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
wxUpdateUIEvent performance issues
dmoore:
This could be a storm in a teacup, but I've lately been scratching my head about the sluggish editor performance on Linux. One potential culprit could be the UI update handling. This issue has come up before: http://forums.codeblocks.org/index.php/topic,5341.0.html
looking in main.cpp I see lots of EVT_UPDATE_UI macros:
--- Code: --- EVT_UPDATE_UI(idFileOpenRecentFileClearHistory, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileOpenRecentProjectClearHistory, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileSave, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveAs, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveAllFiles, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileOpenDefWorkspace, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveWorkspace, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveWorkspaceAs, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileCloseWorkspace, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileClose, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileCloseAll, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFilePrintSetup, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFilePrint, MainFrame::OnFileMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveProject, MainFrame::OnProjectMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveProjectAs, MainFrame::OnProjectMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveProjectAllProjects, MainFrame::OnProjectMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveProjectTemplate, MainFrame::OnProjectMenuUpdateUI)
EVT_UPDATE_UI(idFileSaveAll, MainFrame::OnProjectMenuUpdateUI)
EVT_UPDATE_UI(idFileCloseProject, MainFrame::OnProjectMenuUpdateUI)
--- End code ---
I also see a bunch of Update UI handling in plugins
In the wx docs (http://docs.wxwidgets.org/stable/wx_wxupdateuievent.html#wxupdateuievent) we see the following suggestions:
--- Quote ---If you find that the overhead of UI update processing is affecting your application, you can do one or both of the following:
1. Call wxUpdateUIEvent::SetMode with a value of wxUPDATE_UI_PROCESS_SPECIFIED, and set the extra style wxWS_EX_PROCESS_UPDATE_EVENTS for every window that should receive update events. No other windows will receive update events.
2. Call wxUpdateUIEvent::SetUpdateInterval with a millisecond value to set the delay between updates. You may need to call wxWindow::UpdateWindowUI at critical points, for example when a dialog is about to be shown, in case the user sees a slight delay before windows are updated.
--- End quote ---
Based on the post I linked to at the start, we appear to be following suggestion #2 (line 411 in app.cpp)
--- Code: --- wxUpdateUIEvent::SetUpdateInterval(100);
--- End code ---
but is this enough? Could waking up every 100ms to update the menus explain the poor editing and idle performance of C::B on linux?
see attached, which show the result of logging the # of Editor Menu updates while C::B sits idle with an editor open! They come in at roughly 1 per 100ms, I haven't yet tried to time how much time is spent in these events. However, helpfully, I only see the update spam after an editor has been opened or if I move the mouse around a lot. So I played around with "top" on my lightweight eee pc (note that this is after I switch of the logging I show in the screenshot below -- it's much worse with it on). With no mouse action and all editors closed, C::B generates sits quietly. As soon as I open an editor, C::B jumps to the top of the top queue and doesn't leave it. Similar behavior on windows, but the performance penalty seem to be much more minor...
As far as a fix goes, I think we need to dig in a little and find out why so many update events occur at idle when an editor is open but not when closed...
[attachment deleted by admin]
thomas:
Hmm... this brings up another thing. I've noticed that Code::Blocks really sucks dick if you run it via XDMCP (even on a 1Gbps network with a single Netgear router in between and roughly 4 meters of total cable length).
It takes upwards of half a second (usually more) before Code::Blocks registers a mouse click or opens a menu. I've always wondered why XDMCP performance is so abysmal, especially since other programs run as if they were started locally.
Now, gears in my head start moving... what if this infrequent event polling in combination with the network latency (probably 1ms or less, but still...) is what screws it all up?
dmoore:
--- Quote from: thomas on December 11, 2009, 07:58:17 pm ---Hmm... this brings up another thing. I've noticed that Code::Blocks really sucks dick if you run it via XDMCP (even on a 1Gbps network with a single Netgear router in between and roughly 4 meters of total cable length).
It takes upwards of half a second (usually more) before Code::Blocks registers a mouse click or opens a menu. I've always wondered why XDMCP performance is so abysmal, especially since other programs run as if they were started locally.
Now, gears in my head start moving... what if this infrequent event polling in combination with the network latency (probably 1ms or less, but still...) is what screws it all up?
--- End quote ---
does it just suck only while you have a scintilla window open or for everything? e.g. try opening something in the hex editor (no other windows open) - that doesn't seem to create the idle event spam...
dmoore:
For now I think I give up in disgust. This is a wxWidgets/wxScintilla problem. Something inside of wxScintilla is generating a constant stream of idle events, which in turn spins up the update ui events. That doesn't mean wxScintilla is explicitly sending idle events of course, just that it's doing something to make the wx event loop think its time to send another idle event. I guess it could be something as stupid as the cursor flashing? I've tried overriding wxApp::FilterEvent to see if I could figure out what events were being fired, but didn't see anything obvious besides the stream of update ui and idle events.
As far as performance goes, I guess on windows this isn't an issue at all, and only seems to effect light weight linux systems. Assuming it is worth fixing, I don't think it's enough to block the update ui events, it would be much better to prevent whatever wxScintilla's high frequency activity from generating (so many) on idle events. It's still amusing that we check/uncheck everything in the menubar every 100ms and do more than 100 times just running the mouse from one end of the screen to the other.
dmoore:
I did one more check.... it's the f***ing cursor.
Navigation
[0] Message Index
[#] Next page
Go to full version