[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-bugs
Subject: [Bug 129531] New: kdevelop extremely slow with project with lots of
From: Kevin Bailey <ke-kde () retriever ! dyndns ! org>
Date: 2006-06-21 0:14:29
Message-ID: 20060621021428.129531.ke-kde () retriever ! dyndns ! org
[Download RAW message or body]
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.kde.org/show_bug.cgi?id=129531
Summary: kdevelop extremely slow with project with lots of files
Product: kdevelop
Version: 3.3.2
Platform: unspecified
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
AssignedTo: kdevelop-bugs kdevelop org
ReportedBy: ke-kde retriever dyndns org
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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic