Version: 3.4.1 (using KDE 3.5.7, Debian Package 4:3.5.7.dfsg.1-1 (lenny/sid)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.18-4-k7 After having loaded a project, KDevelop keeps using about 30% of my CPU. Closing the project the CPU usage of KDevelop returns to 0%. Tested with both QMake and Automake projects. Tested with files opened and not opened. Tested with very big projects and very small ones. In all conditions the CPU usage is the same. Note that it is shown as "system" and not "user": 1% - 2% of "user" 20% - 28% of "system" My CPU is an AMD AthlonXP 2200+ (1.8 GHz). I have 512 MB of RAM and it is almost free.
Do you mean it uses these 30% forever? Even if you let it run for lets say 30 minutes it still uses 30% of cpu? If not this bug is invalid, kdevelop does certain things in the background (like parsing the projects files), which takes cpu of course.
I did _a lot_ of tests yesterday before posting that bug report. I worked on a project for hours and it always used 30% of CPU power. Moreover I tested also almost empty project (auto generated files of the project wizard). Today I cannot reproduce it in any way! Probably there is something related to KDevelop because yesterday I tried to close and reload it several times and the bug was always there. Today there was an update of Debian for the sound part of KDE (I'm using KDE 3.5.7, but the audio was still from 3.5.5), probably they broke the update in 2 trunks. May be the audio is related to KDevelop in some way? Anyway I keep doing tests, I found a way to reproduce it, I'll put more infos here, else I'll close the bug. Let me know if there is something I can test which may be related to KDevelop (remember that the CPU usage was "system" and not "user", so may be some underlying process).
No, the kdevelop doesn't have anything to do with the sound stuff of KDE (except that it may play sound-notifications). For QMake projects there's a file-watcher in place that gets notified when a .pro file is changed. However that shouldn't produce 30% cpu unless you change the .pro file or you have a broken notification system (famd is known to be broken, but would itself produce cpu usage). Then as I said, source files are parsed in a background process and thus they're read from disk, but that shouldn't be a problem with a fresh project. I've got no idea what in KDevelop would produce such an amount of cpu usage.
Hi! Today I'm having the same problem. I tried to attach 'strace' to see what's happening. Can the output of strace be of any help to you? Here is the exact command I gave: strace -f -F -s 1024 -p 4382 -o kdevelop_trace.out Where 4382 is the PID of the running kdevelop. I let it run for some tens of seconds, then I closed kdevelop. Tell me if you need other options for strace (like -T or -ttt).
Created attachment 21093 [details] strace attached to running kdevelop strace -f -F -s 1024 -p 4382 -o kdevelop_trace.out
Perhaps, this is yet another manifestation of bug 146144.
is this still reproduceable with an up-to-date version?
I see high cpu usage in KDevelop also if it is running for hours. For me it's only 5-10% (on a CoreDuo T2050). powertop shows there is something going on with timers and mutexes. I'm using KDE 3.5.7 and KDevelop 3.5.0 from openSuSE build.
Please update to KDevelop 3.5.1 for openSuSE. Binaries are available at the usual place: www.kdevelop.org
Still around 5% CPU usage, powertop shows ~100 wakeups/s
Created attachment 23834 [details] strace output of kdevelop Kdevelop is reported to cause >200 wake-ups per second by powertop. Here is the strace output (strace -f -F -s 1024 -p <pid> -o kdevelop_trace.out). I have many, many, many: 7167 <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out) 7167 futex(0x407fffc0, FUTEX_WAKE_PRIVATE, 1) = 0 7167 futex(0x407fff94, FUTEX_WAIT_PRIVATE, 1, {0, 9996780} <unfinished ...> Powertop reports: 27,0% (157,0) kdevelop : schedule_timeout (process_timeout) 16,9% ( 98,4) kdevelop : futex_wait (hrtimer_wakeup)
Sorry forgot to say I'm using kdevelop 3.5.1
this doesn't seem to be a problem in kdev4 anymore.