Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Code Completion question
seb_seb0:
Hello,
I have noticed that when I open large projects (more than 1000 cpp files), CodeBlocks is running, and does not give me the hand (it is not responsive).
I do not know if it is running in an infinite loop on my computer or simply taking a lot of time (more than 5 minutes, after that I kill codeblocks).
For information:
1 I run Codeblocks SVN 84 (nightly)
2 My OS is Windows Vista.
3 My laptop is not a powerful machine (AMD x64 Dual Core TK-55 1.80 Ghz, 2 GB RAM)
4 When I disactivate the CodeCompletion plugin, the project is opened immediately
5 When I use a more powerful PC on Windows XP, it opens the project in a few seconds.
Note that 2 + 3 is a very nasty combination.
My question is then: is it possible to avoid to freeze CodeBlocks when parsing the project ? I understood it was already done with the Parser Threads, but obviously something is running slowly in the main thread.
Thanks in advance for your reply !
Sebastien
oBFusCATed:
You could tells where is the bottleneck with the following procedure:
1. Build C::B from source and enable debug symbols and remove stripping (you should edit update.bat and comment the "strip" commands)
2. Open a console window and navigate to the gdb.exe
2. Make C::B to be stuck somewhere
3. Execute gdb C:\path_to_cb\codeblocks.exe pid_of_cb
4. If gdb doesn't stop C::B, hit ctrl+c, then execute the command "bt" (gdb command) or "thread apply all bt" (this one will print the bt for all threads)
5. Copy and paste (in code tag) the backtrace here.
Hope it helps... :lol:
ollydbg:
--- Quote from: seb_seb0 on November 25, 2010, 10:06:42 pm ---Hello,
I have noticed that when I open large projects (more than 1000 cpp files), CodeBlocks is running, and does not give me the hand (it is not responsive).
--- End quote ---
When loading a new project. CC just do something below:
1, initialization stage.
2, batch parsing
3, update UI
I guess there are some deadlock when codecompletion plugin was doing the initialization stage. I define the "initialization stage" means it just scans all the file names(not the file content) in the current cbp. When after the "initialization stage", parserthread was running as working thread, so at least you can still feel C::B is alive.
--- Quote ---My question is then: is it possible to avoid to freeze CodeBlocks when parsing the project ? I understood it was already done with the Parser Threads, but obviously something is running slowly in the main thread.
--- End quote ---
You can disable the Macro expansion in the CC's configure dialog. which may accelerate the parsing stage, but which will cause some parsing errors.
Note:
CC dose not do "type checking" or other semantic check. it just do a quite naive guess. :D
like:
--- Code: ---id1 id2; //-----> id1 is the "type name" and the id2 is the variable name
id3 id4(); //-----> id3 is the function "return type", id4 is the function name
--- End code ---
So, if you code has a lot of Macro usage, CC's parsing may be in-correct.
As oBFusCATed said.
You can debug CC, it is not hard, and stop CC to see where is the deadly loop.
Anyway, if you still can't find the bug, can you share the source for me to test? :D
ollydbg:
--- Quote from: seb_seb0 on November 25, 2010, 10:06:42 pm ---For information:
1 I run Codeblocks SVN 84 (nightly)
--- End quote ---
which version ??? svn 84????
seb_seb0:
--- Quote from: ollydbg on November 26, 2010, 01:34:20 am ---
--- Quote from: seb_seb0 on November 25, 2010, 10:06:42 pm ---For information:
1 I run Codeblocks SVN 84 (nightly)
--- End quote ---
which version ??? svn 84????
--- End quote ---
LOL - the key "6" is not working properly on my keyboard. You must read 6846
I will try to debug as suggested by Obfuscated and you, and I will let you know.
The project I was trying to visualize is a part of OpenCascade: an Open Source CAD kernel. It is more than 30 000 sources files, so forgive me if I do not send it to you. You can find it here anyway: www.opencascade.org
Sebastien
Navigation
[0] Message Index
[#] Next page
Go to full version