Bug 129531 - kdevelop extremely slow with project with lots of files
Summary: kdevelop extremely slow with project with lots of files
Status: RESOLVED NOT A BUG
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: 3.3.2
Platform: unspecified Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-21 02:14 UTC by Kevin Bailey
Modified: 2007-02-22 19:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Bailey 2006-06-21 02:14:28 UTC
Version:           3.3.2 (using KDE 3.5.3, Debian Package 4:3.5.3-1 (testing/unstable))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.16-1-686

I have a source tree composed of over 10,000 files. When I "import a project" of it, it takes 2 hours and yet doesn't seem to be tagging it. Re-starting kdevelop and reloading the project seems to take the same 2 hours. The CPU is a 2.4GHz Pentium and the source tree is on a local disk, not NFS.

Running exuberant ctags on the project only takes a few minutes, however when I try to edit a file, it seems to spin indefinately using up 99% of the CPU, apparently trying to do some sort of auto-completion. It consumes 300MB doing these activities. (Fortunately, I have 1GB of RAM so it uses no swap space.)

This same source tree can be managed by Visual Slickedit using less than 28MB. On an old 400MHz Sparcstation running over NFS, Slickedit can scan *and tag* this tree in less than an hour. Furthermore, auto-completion while editting takes less than a second.

It seems that Slickedit and ctags have no trouble managing a tree of this size, however kdevelop slows to a crawl when doing even simple operations. To make kdevelop useful for a project this size, it would have to greatly speed up its look-ups, perhaps by using a database with a lower big "O" formula, and it would have to take out the scan when it starts up and loads a project.
Comment 1 Matt Rogers 2006-11-05 15:47:23 UTC
Is it possible for you to provide the project in question for testing? I don't think we'll be able to fix this for the KDevelop 3.x series, but it should already be fixed for the KDevelop 4 series and I'd like to run a few tests.
Comment 2 Andreas Pakulat 2006-11-20 21:29:43 UTC
Can you tell us which type of buildsystem you use (i.e. custom makefiles, qmake, autotools, ...)?
Comment 3 Kevin Bailey 2006-11-21 04:22:49 UTC
Andreas Pakulat wrote:
> 
> ------- Additional Comments From apaku gmx de  2006-11-20 21:29 -------
> Can you tell us which type of buildsystem you use (i.e. custom makefiles,

qmake, autotools, ...)?
> 
> 

We use custom Makefiles.
Comment 4 Jens Dagerbo 2007-01-12 23:17:54 UTC
There is very little in this report beyond conjecture to suggest _what_ is slow in the reported case.

I don't have a 10000 file project handy, but I recently imported KOffice, which is about 4500 source file. It takes about 2 min on my machine for the initial import and about 15 seconds on subsequent startups, reading the codemodel from the project pcs cache. Granted, KOffice is smaller and my machine is faster, but 2 min vs 2 hours?! 

Is maybe the FileGroups plugin active? (It's plenty slow if it has a few regexps configured.)
Comment 5 Kevin Bailey 2007-02-11 20:46:12 UTC
I just upgraded to 3.5 and it just crashes importing a project.
I'm giving up on kdevelop so feel free to close this bug
report.
Comment 6 Andreas Pakulat 2007-02-11 22:09:37 UTC
I guess you mean KDevelop 3.3.5 or 3.3.6 (which come with KDE 3.5.x), please use 3.4.0 instead, which is the current stable release.
Comment 7 Jens Dagerbo 2007-02-22 19:03:24 UTC
Since there is still nothing useful to go on in this BR and the reporter declares he doesn't intend to provide anymore information.. closing it seems like the only sensible thing to do.

INVALID.