symbol browser issue when CB build against wx3.x

[ollydbg]

I build C::B against wx trunk(On windows), I see an interesting issue:

When a new file is opened, the browser tree does not show correctly, see the first image:


Now, you can collapse the root node, see the second image:


And after that, you can expand the root node again, and now you see the correct result(third image):


Please note that the tree in the first image is build from a worker thread, and the tree in the third image is build from the main gui thread(inside the event handler).

It looks like the tree does not work well if it is build from a worker thread. From my point of view, the tree should be only built from the main thread, what's your opinion?

I'm not sure how it works under Linux or Mac.

[oBFusCATed]

Empty tree is the smallest problem. 
Calling ui functions from non-ui threads leads to way more severe problems, like random asserts and crashes.

Morten has started work on a patch that will fix this, but I don't know if it is finished.

[yvesdm3000]

I guess this is part of the builtin code-completion plugin ?

Yves

[oBFusCATed]

Yes, it is part of the plugin, but it should be moved in the sdk and we should provide a common interface, so multiple cc plugins can provide a list of symbols.

[yvesdm3000]

Anyone working on this move ?
In any case, if we want to support 16-01 I guess the Clang-CC plugin should then just copy the implementation or something ?

Yves

[ollydbg]

As of Code::Blocks / SVN Repo / Commit [r11027], the symbol browser is disabled by wx3.0+.

Since constructing a wxTree takes a lot of time, so we need to find a way to build it progressively? Any one knows a good method? We need to move the code in the worker thread to the main GUI thread.

[oBFusCATed]

Probably the best option is to use wxTreeListCtrl in a virtual mode if possible.
But the code is pretty connected to the CC internals and it is not easy to extract it and make it reusable and with good interface, so other plugins can use it.

[ollydbg]

Probably the best option is to use wxTreeListCtrl in a virtual mode if possible.

This sounds interesting.
Any document about wxTreeListCtrl working on the virtual mode? I haven't use such control, but if there is a sample project, I may have a try and see what it's look like. Though the wxTreeListCtrl may look different like our current wxTreeCtrl, because it is a list.

But the code is pretty connected to the CC internals and it is not easy to extract it and make it reusable and with good interface, so other plugins can use it.

Yes, it is connected to the CC internals, not easy to extract it. But before that, we may find a way that first try to move the code from worker thread to gui thread. 

[ollydbg]

I asked a question in wxWidgets' forum, see here: Any method to build a big wxTreeCtrl progressively in GUI thread?, let's see whether we can have good suggestions.

[ollydbg]

Good news, good news, I get some nice answer from wxWidgets' forum, see here
Re: Any method to build a big wxTreeCtrl progressively in GUI thread?

It use a worker thread to dynamically do the dirty work, and construct the child nodes progressively. That is: if you want to add 1000 nodes, you have to send 10 notifications from the worker thread, while in the GUI thread, once received the event, the gui thread will add 100 nodes. It looks like the most time is accessing the TokenTree or search in the TokenTree, so we should still let it in the worker thread, but move the GUI construction in the main GUI thread.

[oBFusCATed]

Do you have a tool to do precise profiling (vtune, perf, ms's xperf)?
If you don't have such a tool then you're guessing and you're probably optimizing the wrong thing.

And fixing this is not a simple matter. The whole thing should be extracted and separated, so multiple plugins can use the same class browser.

[ollydbg]

Do you have a tool to do precise profiling (vtune, perf, ms's xperf)?
If you don't have such a tool then you're guessing and you're probably optimizing the wrong thing.

I don't have such tool, I think there's no such tool for mingw , I see a lot of timer in current symbol browser code. Is timer useful?

[oBFusCATed]

Not much... timers time what is instrumented... sampling profilers time what is being executed...

[yvesdm3000]

Not much... timers time what is instrumented... sampling profilers time what is being executed...

If you can fill the tree progressively and that way you can get the tree filled using a huge set of symbols without anything crashing or blocking, what do you need a profiler for at this stage? Determining the amount of elements in the batch but that's just finetuning and might even never be optimal for any combination of cpu's and architectures except the one measured.

Yves

[oBFusCATed]

Profilers always reveal surprising bottlenecks.  :