| Summary: | sudden slowdown when opening more than 10 windows | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Mark van Rossum <mark.vanrossum> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jtamate, lemma, martinstolpe |
| Priority: | NOR | ||
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | 4.8.0 | |
| Sentry Crash Report: | |||
| Attachments: | kcachegrind view | ||
|
Description
Mark van Rossum
2009-02-08 13:53:59 UTC
This bug is intermittent. I wish I could narrow it down a bit... Seems to have disappeared in 4.2.1. Reopening, because this bug is back in 4.3.4. It took 39sec to open 17 windows ! I think this is not a plasma issue, but a kwin issue. The tests I've done: kwrite 20 small files from the same machine: kwin decoration (aurorae and keramik) with plasma-desktop and with kwin, the last kwrite window took almost 1 second. with plasma-desktop and with icewm, all the kwrite window took the same time. without plasma-desktop and with kwin, the last kwrite window took almost 1 second. nedit 20 small files from a remote idle machine (ssh -X): kwin decoration (aurorae) without plasma-desktop and with icewm, 42 real seconds/31 user cpu seconds to show them all. with plasma-desktop and with icewm, 43 real seconds/31 user cpu seconds. without plasma-desktop and with kwin, 47 real seconds/31 user cpu seconds. with plasma-desktop and with kwin, 50 real seconds/32 user cpu seconds. kwin decoration (keramik) with plasma-desktop and with kwin, 43 real seconds/32 user cpu seconds. I can confirm this on trunk r1184315 using an NVIDIA GeForce 8600 GTS and the 256.35 driver. It happens regardless of desktop effects enabled or disabled. from comment #4 it seems to be related to the decoration. @mark/michael: can you confirm that it's related to the decroation? and erhemm: from the numbers the difference is apparently not in the user but only in the real time, thus kernel/driver related and aurorae actually uses libplasma to render the decoration ;-) After retrying I think it might actually be more related to the application painting itself as it also happens with the Modern System decoration. However with nedit I see a short delay but even after 40 files I'd say it still opens fast enough (almost unnoticeable and not the 1s delay mentioned by the reporter) - thus the main delay seems to be related to Oxygen style using up CPU instead of a bug in KWin. I tried with 41 windows. The nvidia driver has a performance issue with it's pixmap cache (being used to allocate 32bit pixmaps) becoming flooded. Since many oxygen windows will allocate many 32bit pixmaps the cache (might) slow(s) down notably. This would explain the overhead on the system time (any why aurorae is somehow slower than keramik) Notice that while i can confirm this for the css nvidia driver, it does not mean that other drivers do not expose similar issues... Sorry, I can't help any further. I suspect it is the combination Nvidia + KDE, both have been upgraded many times since I reported this bug. I'm now using gnome (+some kde applications) all the time, which works great. Created attachment 52410 [details]
kcachegrind view
What I see in this kcachegrind view, created only opening 94 small .h files with kwrite and then closing them all, is:
KWin::Workspace::createClient uses 9.21 %cpu, called 105 times.
I hope it is usefull.
The cachegrind is 1.1Mib after compression. more than accepted by bko.
what's the state with more recent version of KDE (4.6) and more recent versions of the NVIDIA blob? With 4.8 we have significant performance improvements. The number of open windows should no longer influence the performance at all. Because of that I consider this bug report as fixed. In case you still experience slowdown with 4.8 I would like to ask you to open a new bug report with current information as the bug is rather old. *** Bug 253903 has been marked as a duplicate of this bug. *** |