Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Hourglass in long operations (project loading)
thomas:
--- Quote ---Then we could divide the loading in 2 parts: syncronous and asyncronous.
While the syncronous part is being executed, I think there should be an hourglass (or other). Then the user can start working while the asyncronous part is being done.
--- End quote ---
That's what we're partially doing already, and that's what we will probably extend in the future, as described above.
Showing a hourglass should not be necessary any more once we have had a thorough optimisation pass. Taking into account that we query around 5,000 attributes (which we could fold to around 100-200), needlessly construct-convert-copy-construct around 4,000 wxString objects, and re-calculate the common toplevel path around 200 times while loading codeblocks.cbp (and call wxFileName::Normalize similarly often), there is plenty of opportunity to make the synchronous part faster. Some of these optimisations will not be trivial, though, and some would require changing the project file format.
I shall not commit myself to a precise number, but I think it is not entirely unreasonable to expect reducing the current load time to maybe 25% (or less?) of the current time if putting some serious work into that.
If all the other things that do not necessarily need to run synchronously are moved out of the main line, then you should not have much of a noticeable delay left, so a hourglass should really not be needed at all.
However, it is not optimisation time yet (mandrav dixit). To date, we're happy if we get it to work. Once it works, we can make it faster at a later time.
--- Quote ---Sorry, but a 3 GHz CPU is not so "normal"!
--- End quote ---
Yeah well... a lot of people run 4 GHz and upwards CPUs these days, many of them with either hyperthreading or dual-core (or both). So actually, a plain normal 3 GHz CPU is comparatively slow :)
Don't get me wrong, though. A 4 GHz CPU, 2 GB of physical RAM, and 900 MB of hard disk storage are not and will never be a system requirement to get Code::Blocks running :lol:
--- Quote ---When code completion parsing starts?
--- End quote ---
Immediately after the actual project loading has finished, but before the GUI comes "alive" again.
--- Quote ---Probably the long time I see is related to that.
--- End quote ---
Yes, very likely.
iw2nhl:
Ok.
Seen that for this version the optimizations won't be done and that there is no user feedback that something is occurring, while not show an hourglass for now? It can be removed anytime in the future. It is not a big work, just 1 line of code!
I tried to add it and recompile: the effect is very good. Moreover the program seems to me more responsive because it reacts immediately to the click in the initial HTML page.
(See for this also the 2nd message by Pecan)
About that page, it is not updated at the right time: it should go away just after the click, not when all the project has been loaded.
[EDIT]
Another thing: this problem is not just for "project" loading, but also for files loading.
Try to drag-and-drop 20 or more source files in C::B, it takes a long time and the GUI is freezed.
That single line of code solves this problem too.
killerbot:
I have tried this, I think the hourglass is not that bad, it's good.
However it seems (I stress "seems") I have some crashes on closing Cb (with my cb workspace (the codeblocks.cbp and all contrib cbp's)à. All of them , off course, in the code completion dll. So I don't think the wxBusyCursor is bad, just that darn codecompletion.dll. Since a change 2 months ago it became to me a big pain in the ...
One thing I want to mention about the file loading, 2 weeks ago, I did the same thing opened up 20-30 files at the same time. It ws awfull :
- slow
- CB was like a X-mass tree, those menus flickering ....
We should solve this rather soon then later, and that codecompletion, that it is does not always work and it has it's limitations, but at this moment it's a crash chance of above 50 % :-(
[EDIT] : a few more tries , and no crash now
for everyone's info ;-)
--- Code: ---Error occured on Wednesday, July 26, 2006 at 22:11:07.
E:\data\killerbot\CodeBlocks\svn\src\devel\codeblocks.exe caused an Access Violation at location 65ec2863 in module E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll Reading from location 00690054.
Registers:
eax=08ee8f10 ebx=0a35fcc0 ecx=0069004c edx=0069004c esi=ffffffff edi=00000000
eip=65ec2863 esp=0a35fc24 ebp=0a35fc24 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
65EC2863 E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65EC2863 PluginSDKVersion
65F01A9B E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65F01A9B std::_Rb_tree_const_iterator<int>::operator++() C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_tree.h:255
65E8F081 E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65E8F081 ClassBrowserBuilderThread::AddTreeNode(wxTreeItemId const&, Token*, bool) E:/data/killerbot/CodeBlocks/svn/src/plugins/codecompletion/classbrowserbuilderthread.cpp:276
65E8EC3D E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65E8EC3D ClassBrowserBuilderThread::AddTreeNamespace(wxTreeItemId const&, Token*, std::set<unsigned, std::less<unsigned>, std::allocator<unsigned> > const&) E:/data/killerbot/CodeBlocks/svn/src/plugins/codecompletion/classbrowserbuilderthread.cpp:191
65E8E000 E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65E8E000 ClassBrowserBuilderThread::BuildTree() E:/data/killerbot/CodeBlocks/svn/src/plugins/codecompletion/classbrowserbuilderthread.cpp:103
65E8D867 E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65E8D867 ClassBrowserBuilderThread::Entry() E:/data/killerbot/CodeBlocks/svn/src/plugins/codecompletion/classbrowserbuilderthread.cpp:30
61A609D5 E:\data\killerbot\CodeBlocks\svn\src\devel\wxmsw26u_gcc_cb.dll:61A609D5 _ZN8wxThreadD2Ev
77BCB530 C:\WINDOWS\syswow64\msvcrt.dll:77BCB530 _endthreadex
7D4E0729 C:\WINDOWS\syswow64\kernel32.dll:7D4E0729 FlsSetValue
--- End code ---
thomas:
--- Quote ---Another thing: this problem is not just for "project" loading, but also for files loading.
Try to drag-and-drop 20 or more source files in C::B, it takes a long time and the GUI is freezed.
That single line of code solves this problem too.
--- End quote ---
It does not solve any problem. All it does is show a different cursor. That's following the wrong path. The right path would be to make it behave so it doesn't take that long at all and doesn't freeze.
Besides, the GUI is perfectly responsive under Linux while opening 50 files via D&D (not that it opens them any faster, though). The freeze seems to be a Windows thing.
I have an idea what the reason for D&D being so slow might be, too, but hopefully I am wrong...
--- Quote ---CB was like a X-mass tree, those menus flickering
--- End quote ---
Much of the flickering when opening/closing many files comes from not disabling the editor notebooks. The code was commented out for some reason a long time ago (don't know why). I uncommented it in cf a week or two ago to test whether there are any problems and there seem to be none, so we can probably leave that. It'll eventually get merged.
Another problem is the updating of menus and toolbars in general, but that won't be an easy thing to solve. We are currently doing everything via update_ui events, which is not optimal at all. We are sending way too many events and do way too many things over and over again needlessly.
However, I would not touch that part of the IDE now since Yiannis has implemented his action-based menu system. Tampering with menus now would mean to do useless work, as you would basically have to write a kind of menu manager (which is what we already have).
While it is quite inefficient, the current implementation has one advantage: it works.
--- Quote ---codecompletion, that it is does not always work and it has it's limitations, but at this moment it's a crash chance of above 50 %
--- End quote ---
I don't think we'll ever be able to fix this plugin, nobody understands what is happening anyway. For now (until the new one is production quality), I have code completion entirely disabled, and everything works smoothly. I never see a freeze or a crash (except for the one and only known wxSmith crash-on-exit issue) or any other bad condition.
It's just a shame you don't have "jump to implementation" that way. But then, that never works correctly anyway.
Post tenebras lux... :)
iw2nhl:
--- Quote from: thomas on July 27, 2006, 01:20:29 am ---It does not solve any problem. All it does is show a different cursor. That's following the wrong path. The right path would be to make it behave so it doesn't take that long at all and doesn't freeze.
Besides, the GUI is perfectly responsive under Linux while opening 50 files via D&D (not that it opens them any faster, though). The freeze seems to be a Windows thing.
--- End quote ---
What I mean is that now the code is slow and takes a long time.
When the new code will be ready, we will speak about that way of working.
Now we have another code, a slow code.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version