Symbols browser issue of CC has been fixed for my Linux

[ollydbg]

Miguel Gimenez's patch works OK for my self build C::B.
Thanks!
I would suggest this for the next release.
I will take more time to test it in the future days.

[Miguel Gimenez]

Thank you for testing

[oBFusCATed]

I would suggest this for the next release.

Do you get UI pauses? Because this is a major no-go...

[tigerbeard]

Amazing! Just saw this thread. I have never dreamt that this issue is going to find such a progress so soon.
BIG Thanks to all involved!   

The symbol tree is the only reason I am still stuck with V16. In Linux I actually have used a compiled V17 version with the inhibit switch enabled, so I could use it. I use it quite regulary despite a few crashes  .  Now I understood there is a working version, maybe a bit slower but not crashing. Am I correct that there is not binary for Linux, but I need to get the master, apply the patch and compile it?

I would suggest this for the next release.

+1+1+1+1+1

Do you get UI pauses? Because this is a major no-go...

I can fully understand that someone not using that feature must have reservations about adding a not fully performant piece of UI. But I beg you to re-consider your position. Unless there is no safe way to protect the UI performance when the Symbol browser is diabled, I think this is a special situation. We have the choice between a very useful function (but slow yet) or no useful function at all. As a C::B user I would not like to be locked out of that decision.

And yes I do have quite large projects where a lagging SB might be an issue. But yes I also have a lot of small ones. If if can be safely disabled any time, what are we loosing? Also there are chances to find solutions the old version did not have, e.g. a filter that ignores Macro, Defines, Globals etc that i would hide most of the time (if any of that adds up).

Maybe it would be a compromise to enable the SymbolBrowser switch in the Preferences again, but set it to Off and add a dialog saying "Warning! Feature in Development - this is not fully tested and not profiled yet. Not recommended for production, it will slow down you UI".

[oBFusCATed]

I can fully understand that someone not using that feature must have reservations about adding a not fully performant piece of UI. But I beg you to re-consider your position.

You'll have the right to beg after you try it with your bigger projects.
But this won't help anyway, pauses larger than 10ms are unacceptable.
So if you need the feature start looking at the code with a profiler and try to limit the main thread execution to 10ms.

I'll get to it someday, but at the moment this is very low priority.

[tigerbeard]

You'll have the right to beg after you try it with your bigger projects.

OK got it running in windows (thanks for the new updated User Manual, btw  ! ). So that is Windows feedback only (yet, hope I get Linux to compile it as well soon).

For better coparison I just used the C::B source tree with all addons for a large test project (1200 files. 250k LOC).

• on the initial load it shows content in stages. Its complete after a few seconds.
• reaction of the tree itself feels no different than with V16 (subjective use)
• Scrolling is smooth along the whole tree
• Opening any class is instantanious, no matter where in the tree
• Opening nested structures with namespaces/classes, e.g. ScriptBindings is smooth and instantanious

So I really can not confirm any performance impacts, sorry. Whatever you can measure might be something different, but a negative impact on a fluent work flow could not be seen in this test.   

There is one severe problem for practical use:
 The browser often closes the opened class and jumps to the first entry. It looks like its loosing its postition. It does not happen every time, possibly it has to do with windows not yet loaded. Here is how to Reproduce
     1. open CodeBlocks workspace and switch to Symbols tab. No windows should be open in the editor
     2 scroll to ClassBrowser and open
     3. double click on first memeber var "m_activeFilename: wxString"
    => The header file will open. The class browser closes the class and jumps to the top entry. This closing was on my system delayed by about 1-2secs.
    => It also happens sometimes if the header is open but not the cpp.
    => This does not happen any more if the header file is already open.

[oBFusCATed]

So I really can not confirm any performance impacts, sorry. Whatever you can measure might be something different, but a negative impact on a fluent work flow could not be seen in this test.   

The negative impact is when you're not using it and you're just typing and your typing is interrupted by this feature.

[tigerbeard]

The negative impact is when you're not using it and you're just typing and your typing is interrupted by this feature.

Now I understand why you are mainly interested in the main thread timing. Thanks for clarifying.

Since the tree is built in the main thread (i.e. at initial load) there are two cases for the timing. One when the tree is being actively used (e.g. it just opens a new branch) and the other when its idle/or just displaying its structure unchanged.  A third one could be if its disabled, but I guess its considered unacceptable design if that would still use up performance.
Do the 10ms apply for the first two cases or for the second case only?

 

[oBFusCATed]

Sort of it applies. If something is interacted by the user and there is no feedback that something is happening then this is a problem of the application.

[tigerbeard]

There is one severe problem for practical use:
 The browser often closes the opened class and jumps to the first entry. It looks like its loosing its postition. It does not happen every time, possibly it has to do with windows not yet loaded. Here is how to Reproduce
     1. open CodeBlocks workspace and switch to Symbols tab. No windows should be open in the editor
     2 scroll to ClassBrowser and open
     3. double click on first memeber var "m_activeFilename: wxString"
    => The header file will open. The class browser closes the class and jumps to the top entry. This closing was on my system delayed by about 1-2secs.
    => It also happens sometimes if the header is open but not the cpp.
    => This does not happen any more if the header file is already open.

Update: the error seems to be only applicable when the bottom tree is switched off.

[AZ]

hello,
 any plans to add this patch to nightly build ?

[oBFusCATed]

No, nothing has changed recently and I've stated many times why the current patch is not acceptable.

[tigerbeard]

hello,
 any plans to add this patch to nightly build ?

Sort summary for future readers of this thread:

• There is a patch for the symbol browser code that works for personal use.
• The patch is not ready to be submitted to Master. So to test it you need to:
• copy the patch http://forums.codeblocks.org/index.php/topic,23580.msg160766.html#msg160766 from the post of Miguel Gimenez or the next (git version)
• copy the source code from the repository. I had used trunc11936 and it compiled and worked fine on Linux againt GTK2.
• apply the patch to the sources, e.g using tortoise in Windows or rabbitvcs file manager extension in Linux
• build codeblocks
• report issues in this thread, or upload fixes
• Requirements for submission
• Main thread timing must be <10ms. First it needs to be measured, if not met, the code must be optimzed to meet it.
• First it needs to be measured.
• If the target is not met, the code must be optimzed to meet it.
• Status
• A volunteer is neeed to run a profiler and to do the initial measurements in CodeBlocks.
  The total timing of the SymbolBrowser in the mean thread (and only in the main thread) is needed. All timings of the threads may be ignored. As I understaood the measurement should cover the times if SymbolBrowser is active and well as when it is not active (e.g. another management tab is open). Please post the results in this thead.

[AZ]

@tiger,
  How do i enable symbols browser with wx3 ?  or, as the warning states, it will crash and burn the app?
I really would not want to go back to wx2 - the look&feel is so dated

I applied the patch to latest nightly  12040

[oBFusCATed]

Read the topic from the beginning.