Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Hourglass in long operations (project loading)

<< < (2/8) > >>

iw2nhl:
The file opening seems to be done by the "OpenGeneric()" function.
It is called by:
void MainFrame::OnStartHereLink(wxCommandEvent& event)
bool MainFrame::OnDropFiles(wxCoord x, wxCoord y, const wxArrayString& files)
void MainFrame::OnFileReopenProject(wxCommandEvent& event)
void MainFrame::OnFileReopen(wxCommandEvent& event)
and the 5:
void MainFrame::OnFileImportProject[...](wxCommandEvent& event)

Analizing further more i noticed that "OnDropFiles()" calls it in a for() cicle so I think the hourglass should be put in these 2 functions:
OpenGeneric()
OnDropFiles()
This is to avoid OnDropFiles() showing a flashing hourglass because of the for() cicle.
With this function the hourglass will be asked twice, but it is not a problem because wxBeginBusyCursor() and wxEndBusyCursor() (thanks Game_Ender ;-)) are built for that use (they use a counter for nested calls).
No problems with wxBusyCursor() too (thanks sethjackson ;-)) because it calls the same 2 functions.

[EDIT]
From wxBusyCursor documentation:
just add

--- Code: ---wxBusyCursor wait;
--- End code ---
as first lines of OpenGeneric() and OnDropFiles().

thomas:
Project loading now takes almost exactly twice as long as it used to a couple of months back (for codeblocks.cbp, load time is around 1300 ms on my machine, which is just enough to be annoying). This is due to a several things which were added and which are not optimal. I talked about it with Yiannis a few weeks back.

A hourglass is generally not desired, instead the goal is to make project loading faster and partially asynchronous, so nothing like a hourglass (or progress bar) is needed.

The actual project loading takes only around 30-40 ms for codeblocks.cbp.
Some of the remaining time goes into parsing the project hierarchy (with a major part of CPU time going into the non-inlined cbC2U function and the wxString copy constructor). The major part, however, goes into checking for existing files, file write protection, and most notably, wxFileName overhead.
We haven't even started thinking about optimising the project loader, but that should be done (and will be done) eventually. Only not just now :)

iw2nhl:
NOTE: this is only my opinion!

1)
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.
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 ;-).

2)
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. Think also if loading a project from a slow device (USB, floppy, CD) or if C::B itself is on a slow device. Moreover there are people that use virtual OS (WMWare, QEMU, ...) to make tests and they are very slow.

3)
If you don't like my consideration above, consider at least this:
now loading is very slow also on fast PCs, so why not add a hourglass or something else until that code it optimized?

[EDIT]
- the disabled menu-items problem is visible also on little projects
- the first part of the loading for codeblocks.cbp freezes the program GUI (mouse shape is freezed too), this is another good reason for using an hourglass

thomas:

--- Quote ---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.
--- End quote ---
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.


--- Quote ---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 ;-).
--- End quote ---
This bug is what actually makes it reliable. You can only do certain things after the project was fully loaded.


--- Quote ---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.
--- End quote ---
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


--- Quote ---now loading is very slow also on fast PCs
--- End quote ---
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.

iw2nhl:
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.

Sorry, but a 3 GHz CPU is not so "normal"!

When code completion parsing starts?
Probably the long time I see (about 10 seconds, 1.8 GHz CPU) is related to that.

Navigation

[0] Message Index

[#] Next page

[*] Previous page