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

How to avoid GUI freezing on open/save of large projects

<< < (2/3) > >>

dmoore:

--- Quote from: Bonanza on May 14, 2010, 06:11:45 pm ---I ran first one time because of windows file cache abillity( it took 3:30 min:sec to open my project - this result should be disregarded).

--- End quote ---

it would be cleaner to just disable the plugin from "plugins -> manage plugins"

thomas:
Currently, project loading and saving runs in the main thread, which means that it will do just what you experience, it will freeze the GUI until it is done. This is not normally an issue, however it can be on a SMB share. We're already scheduling several concurrent reads form a worker thread pool and use some buffering tricks to hide at least some of the latencies, but we're not unable to work around some. On local files, the buffer cache takes care of the greatest evil, over SMB, it does not.
A couple of wxWidgets calls do several stat calls and several small reads (this used to be in particular an issue for plugin loading which are zipped, and was the reason why we've implemented an unzip-from-memory-buffer thingie -- wxWidgets would otherwise read the files in chunks of 300-400 bytes at a time, you can imagine what that means over SMB). Each stat adds at least 15-20 milliseconds over SMB (often more), so if you do a few thousand of them, it quickly sums up. Some we can work around, some we have not found a solution yet.

Code completion should not normally make any significant difference other than causing more network traffic and more seeks on the SMB server, as code completion does not run in the main thread.

Moving project loading to a separate thread may be a solution, however I would be very reluctant about putting saving into a separate thread, for it bears great evil. Note that this will not make loading any faster, of course, just the GUI will be more responsive, which makes it somewhat less annoying.

Bonanza:
thank for the explanation thomas.

It seems like this is a matter of some complexity. I am not sure how to continue from here as it seems like there is no easy way. But I think i will be looking a little into the code myself, for my own understandig of the problems.

I guess you experts knows the code like your own pocket, so I have much learning to do:-)

I did some thread investigation by the use of ProcessExplorer from former sysinternal:

And the main thread call stack typically looks like this:

--- Code: ---ntkrnlpa.exe!ZwYieldExecution+0x1c80
ntdll.dll!KiFastSystemCallRet
kernel32.dll!FindFirstFileW+0x16
kernel32.dll!GetLongPathNameW+0x1d2
wxmsw28u_gcc_cb.dll!ZNK10wxFileName11GetLongPathEv+0x57
wxmsw28u_gcc_cb.dll!ZN10wxFileName9NormalizeEiRK8wxString12wxPathFormat+0x3c3
wxmsw28u_gcc_cb.dll!ZN10wxFileName14MakeRelativeToERK8wxString12wxPathFormat+0x51
codeblocks.dll!ZN9cbProject9BuildTreeEP10wxTreeCtrlRK12wxTreeItemIdbbP19FilesGroupsAndMasks+0x689
codeblocks.dll!ZN14ProjectManager17EndLoadingProjectEP9cbProject+0xdc
codeblocks.dll!ZN14ProjectManager11LoadProjectERK8wxStringb+0x173
codeblocks.exe+0x2f5eb
codeblocks.exe+0x2f990
codeblocks.exe+0x31206
codeblocks.exe+0x1b3c
codeblocks.exe+0x6e8a
codeblocks.exe!ZN12cbToolPlugin9BuildMenuEP9wxMenuBar+0xa8
wxmsw28u_gcc_cb.dll!Z12wxInitializeiPPw+0x9a
wxmsw28u_gcc_cb.dll!Z7wxEntryP11HINSTANCE__S0_Pci+0xd8
codeblocks.exe+0x724e
codeblocks.exe+0x56718
codeblocks.exe+0x124b
codeblocks.exe+0x12b8
kernel32.dll!RegisterWaitForInputIdle+0x49

--- End code ---

At least it seems that the code completion plugin is not much in fokus at project load time.

Bonanza:
One additional observation.

If I have a very large project open, and opens a very small project, this also takes a lot of time(CB becomes inresponsive).

This is a little strange to me?
- Maybe the time is spent on re-loading all the files(I think not)? Or
- Maybe the time is spent on re-rendering something like the treeview?

BR Flemming

P.S: I know, I know I should start stepping through the code instead of just asking all the questions. :)

Folco:
To develop on Texas Instruments devices, I use KTIGCC : http://tigcc.ticalc.org/

This IDE has a nice option : "Load files lazily". In fact, files will be opened only when you try to access them, or obviously, compile them.

For C::B, it could work like that :
- C::B open the currently edited file
- other files are opened only if the user wants to access them
- if the Code Completion plug-in is enabled, it opens files of the project which haven't been opened yet. If they do that in a separate thread, it shouldn't freeze the IDE.


Note: it is just an idea, perhaps it is completely stupid because it couldn't be applied to C::B, but I find that it is an handy option, for example in KTIGCC.

Navigation

[0] Message Index

[#] Next page

[*] Previous page