Can't confirm this. The symbols browser refreshes its contents instantly here (using "Active project's symbols" view).

And I used some fairly complex projects to test:

Project 1:

Parsing stage done (888 total parsed files, 30123 tokens in 0 minute(s), 7.385 seconds).

Project 2:

Parsing stage done (1747 total parsed files, 37484 tokens in 0 minute(s), 6.249 seconds).

>> That should be optimized...

Errm, no, we don't optimize what does not need optimization :)

My test was used having the Code::Blocks project and the Help-plugin project. The test is when SWITCHING projects, not when opening new ones.

Steps to reproduce:
1. Have C::B as the active project, and the help-plugin as the other project in your workspace. The class browser tab should be in "active project's symbols". The parsing should include global includes.
2. Start the C::B app, and wait till parsing finishes
3. Double-click on the Help-Plugin project, and then switch to the symbols tab.

You should see a 4-sec delay in the class browser appearing (there's no "class browser updated message").
If not, I'd wonder why it only happens in my machine, because I have an AMD Dual-core 3800+ and 1GB RAM.

I'm trying again... and i see a HUGE blank area to scroll instead of the class browser. The HD is having a lot of activity... I'm scrolling and O.O??? I crashed!!

Error occured on Thursday, June 28, 2007 at 08:39:14.

G:\cb07\codeblocks.exe caused an Access Violation at location 773d747c in module C:\WINDOWS\WinSxS\X86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\COMCTL32.DLL Reading from location 1c7b8bb4.

Registers:
eax=1c7b8b90 ebx=0023f28c ecx=00490055 edx=00000000 esi=00279d28 edi=1c7b8b90
eip=773d747c esp=0023f21c ebp=0023f254 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206

Call stack:
773D747C  C:\WINDOWS\WinSxS\X86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\COMCTL32.DLL:773D747C  Ordinal384
773D8040  C:\WINDOWS\WinSxS\X86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\COMCTL32.DLL:773D8040  Ordinal384
773DA802  C:\WINDOWS\WinSxS\X86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\COMCTL32.DLL:773DA802  Ordinal384
7E398734  C:\WINDOWS\system32\USER32.dll:7E398734  GetDC
7E398816  C:\WINDOWS\system32\USER32.dll:7E398816  GetDC
7E39C63F  C:\WINDOWS\system32\USER32.dll:7E39C63F  IsWindowUnicode
7E39C665  C:\WINDOWS\system32\USER32.dll:7E39C665  CallWindowProcW
641F1910  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:641F1910  _ZN8wxWindow16MSWDefWindowProcEjjl
641F9AFC  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:641F9AFC  _ZN8wxWindow13MSWWindowProcEjjl
642677D4  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:642677D4  _ZN10wxTreeCtrl13MSWWindowProcEjjl
641F2220  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:641F2220  _Z9wxWndProcP6HWND__jjl@16
7E398734  C:\WINDOWS\system32\USER32.dll:7E398734  GetDC
7E398816  C:\WINDOWS\system32\USER32.dll:7E398816  GetDC
7E39B4C0  C:\WINDOWS\system32\USER32.dll:7E39B4C0  DefWindowProcW
7E39B50C  C:\WINDOWS\system32\USER32.dll:7E39B50C  DefWindowProcW
7C91EAE3  C:\WINDOWS\system32\ntdll.dll:7C91EAE3  KiUserCallbackDispatcher
641CD5F4  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:641CD5F4  _ZN11wxEventLoop8DispatchEv
642A2956  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:642A2956  _ZN17wxEventLoopManual3RunEv
6427161E  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:6427161E  _ZN9wxAppBase8MainLoopEv
00405605  G:\cb07\codeblocks.exe:00405605  CodeBlocksApp::OnRun()  G:/projects/codeblocks/src/src/app.cpp:608
6410E477  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:6410E477  _Z14wxUninitializev
64190ACC  C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:64190ACC  _Z7wxEntryP11HINSTANCE__S0_Pci
00401971  G:\cb07\codeblocks.exe:00401971  WinMain  G:/projects/codeblocks/src/src/app.cpp:199
004760AA  G:\cb07\codeblocks.exe:004760AA
004011E7  G:\cb07\codeblocks.exe:004011E7
00401258  G:\cb07\codeblocks.exe:00401258
7C816FD7  C:\WINDOWS\system32\kernel32.dll:7C816FD7  RegisterWaitForInputIdle

Putting the crash aside, notice this behavior:

* Switching from Help-plugin to C::B changes the class browser *INSTANTLY*

* Switching from C::B to help-plugin is when the delay appears. So my assumption is that the bottleneck happens when DELETING items from the class-browser.

Oops... correction. The parsing should *NOT* include "global includes". Just parse preprocessing directives.

Here's a snapshot of the current bug. Notice the large scrolling area in the class browser.

http://www.picturebay.net/img/guests/classbrowserbug.png

Fixed in revision 4258.