I think that loading a project in an asyncronous way is not good because you cannot work on it reliably when it is partially loaded.
This is not true as it is now, and it is not true for the things I was talking about making asynchronous in the future, either.
One of the things I was talking about that could easily run asynchronously was checking for file existence (or read-only flag). Code::Blocks loops through all project files and checks whether the corresponding file exists. If the file does not exist, a "broken file" icon is shown in the tree.
While this is a nice feature, it is generally not a good thing, as it is bound to the access times of a physical disk. We're talking about tens of milliseconds here, not nanoseconds.
Sure enough, there are file system caches, and they do work (otherwise loading the Code::Blocks project would take on the order of 10-15 seconds), but it is certainly not the best performer to run such a thing in the main thread while parsing the project structure.
There is nothing "unsafe" with running such queries asynchronously if proper synchronisation is done. If a file is really missing, you are shown an error if you try to actually open it, anyway. Thus the most "unsafe" thing to happen is displaying the wrong icon for half a second or so while the data is still being fetched. As project files typically
do exist and
are accessible, the chances for this to happen are quite odd.
When I open codeblocks.cbp and I click on a menu, I find some menu-items disabled. This is not good because I think they are not available for a strange reason, while after some seconds thay become available. I see this more like a bug than like a feature ;-).
This
bug is what actually makes it reliable. You can only do certain things after the project was fully loaded.
Loading time depends very much on computer speed, so you cannot say: it should be a fast task to execute. On old PC it may take long time.
I did not say so, and yes indeed, on a slower PC, it will take longer. That's obvious, but that's not the point.
There has been a lot of research in the design of user interfaces, and people are generally more willing to accept a 10 second "busy time" if they are still able to do something than a 500 ms delay if you lock them out entirely (for example by showing a progress bar window or a "busy" cursor).
What we are therefore trying to do (in order of significance) is:
1. make it work
2. make it non-modal, non-blocking, as far as possible
3. make it fast
now loading is very slow also on fast PCs
This is not quite true. On a reasonably "normal" machine (3 GHz, no SMP, no dual-core, no Hyperthreading), project loading takes on the order of 100-200 ms for a small project and on the order of 1.2-1.4 seconds for a project the size of Code::Blocks. Most IDEs are
significantly slower than that. Even though we have not yet spent one minute optimising the project loader, we really don't need to hide under a rock.
The thing that really takes a very long time to get running is the code completion plugin (up to tens of seconds). For some reason which I don't remember, it blocks parts of the toolbar and menus, too. However, this has nothing to do with project loading per se.
