User forums > Using Code::Blocks

Bug Report: [#18755] C::B hangs for 20 seconds while opening large project...

<< < (4/20) > >>

rickg22:
Okay, I compiled C::B and started debugging...

Here's some info so far:

projectmanager.cpp:786: EndLoadingProject(result) takes around 40 seconds (in debug mode);
projectmanager.cpp:794: SetProject(result,true) takes from 20 to 30 seconds.

I'll run a detailed walktthrough in the next pass.

EDIT:

Okay, more fine-grained stuff:

projectmanager.cpp: 3101 project->BuildTree(m_pTree, m_TreeRoot, m_TreeVisualState, m_pFileGroups);

This takes most of the running time.

Something puzzled me, however. This builds the tree. Why is it then that in a later stage, in ProjectManager::SetProject (lines 482-483), the tree is rebuilt AGAIN? We just built it! :( (Oh, nevermind. It's the workspace tree, not the project tree)

Anyway, most of the delay is in project->BuildTree. I'll go into more detail tomorrow, it's getting late.

rickg22:
Okay, I've been thinking....

If Life gives you lemons, don't make lemonade...  :P

Now, seriously. The following lines seem to make a lot of noise:


--- Code: ---        
        wxFileName nodefile = f->file;
        nodefile.MakeRelativeTo(m_CommonTopLevelPath);
        wxString nodetext = nodefile.GetFullPath();
        FileTreeData::FileTreeDataKind folders_kind = FileTreeData::ftdkFolder;

--- End code ---

 (I haven't been able to profile them yet, how do you profile that part?)

If I recall correctly, wxFileName does depend on some Operating System stuff to do its calculation. So, here's an idea: Why do we have to recalculate all these relative paths over and over for the files belonging to the same directory?

Why not storing the resulting relative filenames in a hash table? Even better, why not do the calculation first for all the directories, and THEN use the obtained values for the rest of the files? We can know if two files belong to the same directory, right? It would be matter of assigning a numeric id to each directory, and ta-da!

(This is, if most of the time spent is really in the path calculation and not in the actual widget building)


EDIT: Oh, I forgot to post the dll dependencies. Here they are.

--- Code: ---From        To          Syms Read   Shared Object Library
0x77b01000  0x77c65d1c  Yes (*)     C:\Windows\system32\ntdll.dll
0x75561000  0x7565bd58  Yes (*)     C:\Windows\syswow64\kernel32.dll
0x76ca1000  0x76ce6a18  Yes (*)     C:\Windows\syswow64\KernelBase.dll
0x76f81000  0x7702b2c4  Yes (*)     C:\Windows\syswow64\msvcrt.dll
0x75d11000  0x76959898  Yes (*)     C:\Windows\syswow64\shell32.dll
0x75831000  0x75886b60  Yes (*)     C:\Windows\syswow64\shlwapi.dll
0x75bb1000  0x75c2292c  Yes (*)     C:\Windows\syswow64\gdi32.dll
0x758c1000  0x759a4198  Yes (*)     C:\Windows\syswow64\user32.dll
0x75ae1000  0x75b7f04c  Yes (*)     C:\Windows\syswow64\advapi32.dll
0x76b21000  0x76b38ed8  Yes (*)     C:\Windows\SysWOW64\sechost.dll
0x77151000  0x77225e04  Yes (*)     C:\Windows\syswow64\rpcrt4.dll
0x751e1000  0x752221f0  Yes (*)     C:\Windows\syswow64\sspicli.dll
0x751d1000  0x751db474  Yes (*)     C:\Windows\syswow64\cryptbase.dll
0x75ba1000  0x75ba92f8  Yes (*)     C:\Windows\syswow64\lpk.dll
0x75c41000  0x75cdc9fc  Yes (*)     C:\Windows\syswow64\usp10.dll
0x751a1000  0x751a40f0  Yes (*)     C:\Windows\SysWOW64\shfolder.dll
0x6e941000  0x6e96373c  Yes (*)     C:\MinGW\bin\libgcc_s_dw2-1.dll
0x6fc41000  0x6fd3495c  Yes (*)     C:\MinGW\bin\libstdc++-6.dll
0x62701000  0x62ddc6c0  Yes         C:\projects\wxWidgets\wxMSW-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
0x72b31000  0x72ccd18c  Yes (*)     C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
0x76b91000  0x76c0a39c  Yes (*)     C:\Windows\syswow64\comdlg32.dll
0x76cf1000  0x76e4b0cc  Yes (*)     C:\Windows\syswow64\ole32.dll
0x756b1000  0x7573e644  Yes (*)     C:\Windows\syswow64\oleaut32.dll
0x73a71000  0x73aa1264  Yes (*)     C:\Windows\SysWOW64\winmm.dll
0x736f1000  0x737407a0  Yes (*)     C:\Windows\SysWOW64\winspool.drv
0x73951000  0x73956108  Yes (*)     C:\Windows\SysWOW64\wsock32.dll
0x75671000  0x756a4784  Yes (*)     C:\Windows\syswow64\ws2_32.dll
0x77ad1000  0x77ad5058  Yes (*)     C:\Windows\syswow64\nsi.dll
0x00de1000  0x01336718  Yes         c:\projects\cb\src\devel\codeblocks.dll
0x6e441000  0x6e4f93c0  Yes         c:\projects\cb\src\devel\wxpropgrid.dll
0x75361000  0x753a1ce0  Yes (*)     C:\Windows\SysWOW64\imm32.dll
0x76eb1000  0x76f7bebc  Yes (*)     C:\Windows\syswow64\msctf.dll
0x73811000  0x73872a7c  Yes (*)     C:\Windows\SysWOW64\uxtheme.dll
0x6fe71000  0x6fe8299c  Yes (*)     C:\Windows\SysWOW64\dwmapi.dll
0x736d1000  0x736e57b2  Yes (*)     C:\Windows\SysWOW64\cryptsp.dll
0x73691000  0x736ca244  Yes (*)     C:\Windows\SysWOW64\rsaenh.dll
0x72811000  0x7281d7ac  Yes (*)     C:\Windows\SysWOW64\RpcRtRemote.dll
0x743d1000  0x74463f78  Yes (*)     C:\Windows\SysWOW64\msftedit.dll
0x6bd81000  0x6bd99ba0  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\abbreviations.dll
0x712c1000  0x71312cb4  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\astyle.dll
0x64381000  0x64395a68  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\autosave.dll
0x6af01000  0x6af1df1c  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\classwizard.dll
0x65e81000  0x65fa41f0  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\codecompletion.dll
0x64b01000  0x64c6ca48  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\compiler.dll
0x6d881000  0x6d8fcf18  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\debugger.dll
0x649c1000  0x649dc2a8  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\defaultmimehandler.dll
0x69041000  0x690515e4  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\openfileslist.dll
0x70501000  0x705335f8  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\projectsimporter.dll
0x63c01000  0x63c4a6e0  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\scriptedwizard.dll
0x6bac1000  0x6baecacc  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\todo.dll
0x62301000  0x6230d474  Yes         c:\projects\cb\src\devel\share\codeblocks\plugins\xpmanifest.dll
0x739f1000  0x73a3b464  Yes (*)     C:\Windows\SysWOW64\apphelp.dll
0x72b21000  0x72b2404c  Yes (*)     C:\Windows\SysWOW64\msimg32.dll
(*): Shared library is missing debugging information.

--- End code ---

MortenMacFly:

--- Quote from: rickg22 on October 17, 2012, 07:36:28 am ---(I haven't been able to profile them yet, how do you profile that part?)

--- End quote ---
wxStopWatch with a DebugLog output, maybe?

Jenna:
On linux it takes less than a second for a project with more then 7000 files (one of my wxWidgets test-projects).

But I noticed one thing, that can increase the loading time a lot:
At first run (when opening a project or workspace), we always call BuildTree() and RebuildTree() for the project.
RebuildTree() deletes the content of the tree and rebuilds it from scratch.
I think this should be avoided if possible.

I have no time to look into it at the moment, maybe later this week, if I am back home.

dmoore:
Using wxStopWatch I can confirm that almost all of the opening time is spent on wxFileName::MakeRelativeTo. Rebuilding the tree control isn't all that expensive.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version