Yiannis: I believe it may be related to the lexers. If you use way less lexers it seems to work faster.There seems to be no difference, even if I remove all lexers except the c++-lexer.
@all: Can you try that, please?
If no files are to be opened the project opens almost immediately.I've opened all files in my debugger_gdbmi plugin, closed the workspace and opened it again.
Yiannis: I believe it may be related to the lexers. If you use way less lexers it seems to work faster.
@all: Can you try that, please?
The exact problem I 'm seeing is that it takes a *lot* of time (about a second each) to reopen each previously opened file while loading the project.It may be related, just for the record: I experienced a different bad bug: If I open a WS with many projects (~15-20) and files are being opened due to the layout, sometimes CC freaks out and never stops parsing. This only happens if file were opened, but I didn't find a way to reproduce. There seems no logic behind.
One thing that speeds up loading of large files a lot is moving SetLanguage(HL_AUTO) from SetEditorStyleBeforeFileOpen to SetEditorStyleAfterFileOpen.Nice catch, Jens.
Parts of it are already in svn, the needed define is "fileload_measuring", but it does not cover all parts.One thing that speeds up loading of large files a lot is moving SetLanguage(HL_AUTO) from SetEditorStyleBeforeFileOpen to SetEditorStyleAfterFileOpen.Nice catch, Jens.
However, I recall that this call was moved to that place for some reason (fixing a bug) recently... Or am I wrong (I cannot consult SVN blame/log for the moment)?
In addition: Can you commit the instrumentation concerning measuring the times needed to SVN and making it "toggle-able" with a #define? I feel as if we'll need this again in the future... :)
At the moment I use a much more finegrained debug-output, but that can not be committed, because it litters the sources with tons of ifdefs.Why don't you add something like
#ifdef CB_FILELOAD_MEASURING
CB_FILELOAD_PRINT printf
#else
#define CB_FILELOAD_PRINT(...)
#endif
Please test and give feedback.
It's not (yet) tested on windows.I can't try for the moment (I am on holiday ;-)). Did Yiannis try on Windows?!
I'm at home but the children are in holiday (except my youngest daughter), nearly as good.It's not (yet) tested on windows.I can't try for the moment (I am on holiday ;-)).
Did Yiannis try on Windows?!I tried in the meantime and it also works, but without this great improvement.
It's not (yet) tested on windows.Did Yiannis try on Windows?!
OK, unfortunately this does not work for me on Windows. What happens is that the option to use #defines is ALWAYS set to true whenever I open a file. When I go to editor settings, enable and again disable the option the colouring is correct again. However, opening the next file the setting is again ignored. :-(Folding is also broken, but I'm working on another patch, that seems to speed loading of very large files much more, but respects folding.
Jens you have very strange method for calculation your performance boost....I added it to the original post.
For example in "C::B core" the gain is something like 6x, not 84% -> 22.9/3.6 = 6.36 times faster :)
Here comes the new patch (attached) and some mesurements I have made:OK, tested on Windows and suddenly I get strange crashes on shutdown (rarely, luckily) that may be related. Here's the trace:
Hi
I posted another thread about very similar topic here http://forums.codeblocks.org/index.php/topic,14644.0.html .
I have got there response with link to this thread. On the first view it looks like it is the same problem I experiencing however I think that you are fighting another one.
If I understand correctly, this thread is beating the slow opening of project with already opened files (reopening those previously opened files in the editor). I am fighting the problem of opening new project and/or creating new project with many files. Please correct me if I am wrong.
By the way I disabled and then removed all plugins (by removing them from the disk) and it had no influence to the loading speed. I think that the reason is that plugins do not come to the scope at the time of creating of the virtual folder's tree.
An on the end I can contribute to fighting your problem. From my experience the big speed up comes when you disable automatic completion update (what is probably done every keypress) and instead of this let it be updated every "file save". This can be set somewhere in editor settings.
I already have read your other post and will try to look into it.
I use the linux-kernel sources as test project (just to load it, not to compile or anything).
wxHashSet (codecompletion disabled)
open linux-kernel 2.6.35
23:50:31,744 => cbEVT_EDITOR_CLOSE
Loading project file...
Parsing project file...
23:50:32,141 => cbEVT_PROJECT_RENAMED
23:50:32,149 => cbEVT_BUILDTARGET_ADDED
23:50:32,149 => cbEVT_PROJECT_TARGETS_MODIFIED
Loading target Debug
23:50:32,150 => cbEVT_BUILDTARGET_ADDED
23:50:32,150 => cbEVT_PROJECT_TARGETS_MODIFIED
Loading target Release
Loading project files...
23:50:32,175 => cbEVT_PROJECT_BEGIN_ADD_FILES
23:50:35,732 => cbEVT_PROJECT_END_ADD_FILES
33115 files loaded
Done loading project in 3991ms
Project's base path: /home/jens/kernel-tmp.2.6.35/
Project's common toplevel path: /home/jens/kernel-tmp.2.6.35/
23:50:39,498 => cbEVT_PROJECT_OPEN
23:50:39,499 => cbEVT_WORKSPACE_CHANGED
23:50:43,138 => cbEVT_PROJECT_ACTIVATE
23:50:43,142 => cbEVT_BUILDTARGET_SELECTED
and close it
Removed test from all deps
23:53:53,051 => cbEVT_EDITOR_SWITCHED
23:53:53,138 => cbEVT_EDITOR_ACTIVATED
23:53:53,259 => cbEVT_PROJECT_CLOSE
23:53:58,248 => cbEVT_BUILDTARGET_SELECTED
23:53:58,289 => cbEVT_WORKSPACE_CHANGED
23:53:58,431 => cbEVT_APP_ACTIVATED
23:53:58,447 => cbEVT_EDITOR_SWITCHED
23:53:58,516 => cbEVT_EDITOR_ACTIVATED
trunk
open
23:55:21,116 => cbEVT_EDITOR_CLOSE
Loading project file...
Parsing project file...
23:55:21,345 => cbEVT_PROJECT_RENAMED
23:55:21,354 => cbEVT_BUILDTARGET_ADDED
23:55:21,355 => cbEVT_PROJECT_TARGETS_MODIFIED
Loading target Debug
23:55:21,355 => cbEVT_BUILDTARGET_ADDED
23:55:21,355 => cbEVT_PROJECT_TARGETS_MODIFIED
Loading target Release
Loading project files...
23:55:21,379 => cbEVT_PROJECT_BEGIN_ADD_FILES
23:56:43,454 => cbEVT_PROJECT_END_ADD_FILES
33115 files loaded
Done loading project in 82341ms
Project's base path: /home/jens/kernel-tmp.2.6.35/
Project's common toplevel path: /home/jens/kernel-tmp.2.6.35/
23:56:47,745 => cbEVT_PROJECT_OPEN
23:56:47,746 => cbEVT_WORKSPACE_CHANGED
23:56:51,936 => cbEVT_PROJECT_ACTIVATE
23:56:51,962 => cbEVT_BUILDTARGET_SELECTED
and close it
Removed test from all deps
23:58:36,742 => cbEVT_EDITOR_SWITCHED
23:58:36,762 => cbEVT_EDITOR_ACTIVATED
23:58:36,876 => cbEVT_PROJECT_CLOSE
23:58:38,597 => cbEVT_BUILDTARGET_SELECTED
23:58:38,671 => cbEVT_WORKSPACE_CHANGED
23:58:38,886 => cbEVT_APP_ACTIVATED
23:58:38,906 => cbEVT_EDITOR_SWITCHED
23:58:38,997 => cbEVT_EDITOR_ACTIVATED
Updated wxHashSet-patch (against svn r7546).Jens, after testing for a couple of days I think this patch still has serious issues. I am facing the following strange phenomena:
I will check for misiing nullpointer-checks as soon as possible (I never had any crashes).I think that was the only one. The crash in that case is gone.
And of course test all others issues you have described also.Besides the project file changes the only major remaining issue is in the project properties dialog: You don't even need to copy a target. The build file list is always empty. And if you click into it C::B crashes w/o backtrace (!). Looks its related to the fact that you set the project file as client data to the checked list...
I will check for misiing nullpointer-checks as soon as possible (I never had any crashes).I think that was the only one. The crash in that case is gone.And of course test all others issues you have described also.Besides the project file changes the only major remaining issue is in the project properties dialog: You don't even need to copy a target. The build file list is always empty. And if you click into it C::B crashes w/o backtrace (!). Looks its related to the fact that you set the project file as client data to the checked list...
Either it's a windows-special, or you need to do a really clean build, with manually removed pch's etc. .Maybe, the crash is like:
#0 BAADF00D ?? () (??:??)
#1 627FB36C wxListBox::MSWOnDraw(void**) () (C:\Devel\wxWidgets\lib\gcc_dll\wxmsw28u_gcc_custom.dll:??)
#2 0028ACA4 ?? () (??:??)
#3 ?? ?? () (??:??)
Please note that wxCheckListBox uses client data in its implementation, and therefore this is not available to the application.
Sometimes...Unfortunately it works on linux, and so I did not stumble over it.
Look here:
http://docs.wxwidgets.org/2.8/wx_wxchecklistbox.html
It states:QuotePlease note that wxCheckListBox uses client data in its implementation, and therefore this is not available to the application.
That's probably the actual issue. And it works again, if I don't set the ClientData. Surely this is not an option - looks we need another solution to store the ProjectFile pointer.
EDIT: Reminds me: Do you actually clear the ClientData somewhere? Otherwise it's probably a memory leak, in addition...
The client-data is just a pointer to a projectfile.Ah - OK. I missed that.
I attach a new one, which does not use the ClientData, sorts the files in the list correctly and also sorts the files in the project-files correctly.Tested and looks good. From my perspective the patch is ready to go - I clearly see speed improvements. I would commit a couple of very tiny refinements if you did afterwards.
Tested and looks good. From my perspective the patch is ready to go - I clearly see speed improvements. I would commit a couple of very tiny refinements if you did afterwards.
Jens: why have you left some commented code in /trunk/src/sdk/cbproject.cpp ?...because that was my duty... ;-)