Super slow opening workspaces

[Lotharyx]

Hi,

CodeLite 9.1.0 binary from codelite apt repo
Debian Jessie
gcc-4.9 selected for workspace

It takes an extremely long time (over 60 seconds!) to open a wxFormBuilder-enabled workspace with only 2 files. I have disabled all plugins via plugin manager (cleared all checkboxes) and the performance is the same.

The computer is built around Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz w/ 8GB RAM (>2 GB free). There is no apparent heavy CPU usage during the wait time.

I am new to CodeLite and this forum, so please forgive me if this is just something stupid I've done!

[DavidGH]

Hi,

That's impressively slow. I use jessie, though with a faster cpu (AMD FX8350, 8 cores) so to be more comparable I tested in a virtualbox jessie instead. A new wxFB workspace loaded in about 2 seconds. Starting CodeLite with that workspace selected took less than 10 seconds.

Have you tried a different type of workspace? Is there anything special about your system e.g. is the workspace on an NFS partition or similar?

Could you try debugging the load? Ideally that would mean building a debug version, then running it in gdb (standalone or inside a CodeLite instance) and break during the opening process to see where it's stuck.

Regards,

David

[Lotharyx]

Is there anything special about your system e.g. is the workspace on an NFS partition or similar?

Mm, yes, I didn't think of it because it's such a standard part of my usage. The workspace is on a CIFS mount. Let me see what happens when I create a workspace on local storage.

[Lotharyx]

Is there anything special about your system e.g. is the workspace on an NFS partition or similar?

Let me see what happens when I create a workspace on local storage.

Well. That makes all the difference in the world. But... why would a remote system that is ordinarily quite responsive lead to such a massive slowdown in CodeLite? I suppose I should build a debug CodeLite and break in during the wait?

[eranif]

My first guess would be the sqlite symbols database.
Before you run and build a debug version, try enabling CodeLite logging from settings->preferences->misc->log->CodeLite Log-file verbosity->Developer
And post the file: ~/.codelite/codelite.log here (please clear it before you do that)

Eran

[Lotharyx]

My first guess would be the sqlite symbols database.

Oh, yeah, if there's a sqlite DB in the project directory getting heavy activity (and indeed, the "parsing workspace" takes several minutes to complete), that would explain a lot. If that's true, is there a way to have CodeLite place that file in another location?

The log file grew to 36,058 lines, so I gzipped it. The vast, vast majority of entries (35,285 lines) are [CACHE CLEARED], many of which are five milliseconds apart.

Obviously the simplest answer is to work on a local copy, but I suspect working on files on a remote resource is common enough to investigate this. Thanks to everyone who is involved so far!

[eranif]

Please open a feature request for placing the .tags files under a different location

Eran