Author Topic: How to avoid GUI freezing on open/save of large projects  (Read 21334 times)

Offline Bonanza

  • Multiple posting newcomer
  • *
  • Posts: 34
  • Engineer
How to avoid GUI freezing on open/save of large projects
« on: May 14, 2010, 01:11:26 pm »
Hi All,

Yesterday I had Codeblocks run with my favorite debug equipment "lauterbach" based on the plugin from lauterbach themselves.

Now there is absolutely no doubt for me that Codeblocks and I fit together:-)

I want, to spread the news for all my collegues, but there is one medium size anoyance that I would like to have solved before I do so. And also this have stoppede some of my colleagues from using Codeblocks.

-----

The annoyance is the load time for a large project containing approximately 2500 c/h files. It takes about 3.5 minutes to load the project.

Something similar happends if you add a file and want to save the project this takes about 1-2 minute.

The load and save times are of course acceptable but the fact that you totally loose contact to the user interface of Codeblocks is not that nice.

I must add that we are working on windows machines, and the source is placed on a samba drive.

But the same behaviour is seen when loading from windows, just not the same magnitude.

-----

To keep this post constructive I would like to sign myself in for trying to solve this "annoyance".

But before I start looking at the code, maybe someone could give me an indication if this is even possible and where to look in the code, which blocks are involved.

I know that programs like "beyond compare" and "source insight" can handle that you point out a large number of files for your concern. But while all these files are parsed and checked in some way in the background you can still start your work.

I am thinking some more threading of some kind, but this is likely not a trivial change to Codeblocks, so I throw this post as a starting survey.

BR Flemming 
« Last Edit: May 14, 2010, 01:13:34 pm by Bonanza »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: How to avoid GUI freezing on open/save of large projects
« Reply #1 on: May 14, 2010, 01:27:59 pm »
Is it possible related to the CC (CodeCompletion plug)?
For me, I experience several seconds GUI freezing when loading the Codeblocks.cbp project. Not sure how to solve it.. :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Bonanza

  • Multiple posting newcomer
  • *
  • Posts: 34
  • Engineer
Re: How to avoid GUI freezing on open/save of large projects
« Reply #2 on: May 14, 2010, 01:52:18 pm »
I heard that also...

But couldn't it just run in the background somehow, like on "source insight" e.g.?

Some suggested to turn it off in some other posts, but i actually use the CC and it would be okay that it was not ready for the first few minutes.

That is the question I am looking into:-)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: How to avoid GUI freezing on open/save of large projects
« Reply #3 on: May 14, 2010, 04:31:46 pm »
have you tried opening with/without CC enabled?

As far as I know, CC does most of its heavy lifting on threads (but it's possible it causes unnecessary delays on project open)

If you want a generally more responsive UI during project load (and save), perhaps the best way will be to put the project file parsing (or writing) onto a separate thread and progressively send messages to the GUI/main thread (adding files etc).

Offline Bonanza

  • Multiple posting newcomer
  • *
  • Posts: 34
  • Engineer
Re: How to avoid GUI freezing on open/save of large projects
« Reply #4 on: May 14, 2010, 06:11:45 pm »
OK I tried out the CC setting. Please correct me if I am wrong, but I went to the:
Settings->Editor->Code-completion and symbol browser page and selected "Disable code-completion" checkmark.

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

So here it comes:
Code completion "disabled": 2:57 min:sec or so;
Code completion not "disabled": 3:02 min:sec or so

So there is not much difference between "to CC or not to CC" on my machine.

BTW: Let me also mention that I am using Build 6080 of codeblocks.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: How to avoid GUI freezing on open/save of large projects
« Reply #5 on: May 14, 2010, 06:40:25 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).

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

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: How to avoid GUI freezing on open/save of large projects
« Reply #6 on: May 14, 2010, 06:43:03 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Bonanza

  • Multiple posting newcomer
  • *
  • Posts: 34
  • Engineer
Re: How to avoid GUI freezing on open/save of large projects
« Reply #7 on: May 14, 2010, 08:38:46 pm »
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

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

Offline Bonanza

  • Multiple posting newcomer
  • *
  • Posts: 34
  • Engineer
Re: How to avoid GUI freezing on open/save of large projects
« Reply #8 on: May 31, 2010, 09:21:45 am »
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. :)

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: How to avoid GUI freezing on open/save of large projects
« Reply #9 on: May 31, 2010, 11:07:29 am »
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.
« Last Edit: May 31, 2010, 08:14:49 pm by Folco »
Kernel Extremist - PedroM power ©

Offline Halan

  • Multiple posting newcomer
  • *
  • Posts: 43
Re: How to avoid GUI freezing on open/save of large projects
« Reply #10 on: May 31, 2010, 06:00:14 pm »
On Linux I experience this problem more extreme when closing C::B. Then the GUI freezes and GNOME often asks me if i wan't to kill Codeblocks (because it doesn't respond)