Time used to open a file

[Folco]

Hi,

I use two versions of C::B :
- nightly 7075 under Win XP Pro SP3 (32b)
- current SVN under Kubuntu (64b)

I am currently on a new project which is about ~15 files (this is a C project, but I got same behavior with other projects, like assembly or C++ programs).
When I open this project under Win and nux, it take about 1/10 second under Win, and perhaps 5 seconds under nux. Why is there such a great difference ? I have always noticed that, but didn't asked about that. Any idea ? Is there a way to speed up opening time under Linux ?

(hmmm, the topic title should be "Time used to open a project"...)

[stahta01]

The Linux Folks Un-Install all the plugins they do not use; because it takes noticeable time to load the disabled plugins under Linux.
No idea if that is your problem.

Note: I would try to disable/uninstall Code Completion first.

Tim S

[oBFusCATed]

I have a workspace with 5+ project it opens for 1-2 seconds.
The cb project opens for 1-2 seconds, too.

Try disabling some of the plugins. Starting with CC.

p.s. is it slow the second time you open it?

[Folco]

Ok, thanks for your answers. Indeed, I compile by hand under Linux, and I perform a ./configure --with-contrib-plugins=all. I'll try only with the plugins I really use, then I will try disabling CC.

I'm currently under Win, but I test soon.

[Folco]

My internet was down yesterday, so I didn't recompile, but what I can say is that :
- the second time I open a project, the time used is the same than the first one
- disabling CC doesn't change anything

[mandrav]

I 'm experiencing the same issue too and I 'm planning to investigate it more in the next few days. As soon as I find the culprit, I 'll fix it. Please be patient.

[MortenMacFly]

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?

[Jenna]

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?

There seems to be no difference, even if I remove all lexers except the c++-lexer.
Also all plugins except the compiler-plugin have been removed.

I opened the C::B project with some files (less than 10) open.
If no files are to be opened the project opens almost immediately.

[oBFusCATed]

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.
The second opening took 2-3 seconds, it was relatively fast, but it is slower than no-files-to-be-opened case.
I could see how every file is opened, then redrawn, bla bla...

[mandrav]

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?

I think not.
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. When opening a project that has no open files in the layout, the loading is blazingly fast.
From a very quick glance I had the other day, I feel it's the creation of the editors that's slowing everything down. I will investigate more though.
At first I suspected the encoding detection but that takes a couple of milliseconds so that's not it.

[MortenMacFly]

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.

However, (on second thoughts) as Jens said CC is disabled for him it may be a another issue... but still: it could be related. I've disabled the option to re-open files for exactly that issue, so I didn't realise the issue you mentioned.

(I've no access to C::B at the moment btw...)

[Jenna]

One thing that speeds up loading of large files a lot is moving SetLanguage(HL_AUTO) from SetEditorStyleBeforeFileOpen to SetEditorStyleAfterFileOpen.

All measurements are made with a lot of debug statements in the code, that write to C::B's debug-log, that's one of the causes for the very long overall loading time.

For a 3.5 MB test cpp-file the load-time changes from 6.349 s to 1.654 s (74 % better).
Load-time of a web-project (all files opened) that contains mainly small php,js and css-files decreased from 40.614 ms to 36.501 ms (10 % better).
C::B project's load-time changes from 8 m 56.375 ms to 7 m 37.214 s (15 % better).

This change can decrease the loadtime depending on the filesizes a lot or at least a little bit, but it should not harm in any cases.
Any tests are welcome, to ensure there are no side-effects.

There are at least two other places where a little more time is needed:
Sending the cbEVT_EDITOR_ACTIVATED-event in void EditorManager::SetActiveEditor(EditorBase* ed) and the call to m_pControl->GotoPos(m_pProjectFile->editorPos) (and m_pControl2->GotoPos(m_pProjectFile->editorPos_2) if editor is in split-view) in void cbEditor::SetProjectFile(ProjectFile* project_file, bool preserve_modified) also take a resonable amount of time. The second is a call to a scintilla-function and therefore not so easy to change (without hacking scintilla).
The first only needs to be called if the editor is the topmost editor, but is called for every editor that gets opened via cbEditor* EditorManager::Open(LoaderBase* fileLdr, const wxString& filename, int /*pos*/, ProjectFile* data) at the moment.

[MortenMacFly]

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...

[Jenna]

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...

Parts of it are already in svn, the needed define is "fileload_measuring", but it does not cover all parts.
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.

svn blame does not really work for some commits, because when remerging cc-branch wit trunk (or aui-branch I do not remember exactly) the sourcees have been copied instead of doing a real merge (that was broken as far as I know).

One major bottleneck was fixed two years ago:
http://forums.codeblocks.org/index.php/topic,10552.msg72360.html

If I remember correctly, I also did something with SetLanguage, but I do not recall exactly what it was, I will search the websvn to find if there is anything related.

[oBFusCATed]

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

Code

#ifdef CB_FILELOAD_MEASURING
CB_FILELOAD_PRINT printf
#else
#define CB_FILELOAD_PRINT(...)
#endif