| Summary: | Plasma Dashboard initialization is slow. | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Joe Kowalski <joekowalski> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | finex, grigoresculiviu, kde, l.lunak, nash |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Opreport dump of 1 initialization of the dashboard. | ||
|
Description
Joe Kowalski
2008-01-13 19:50:04 UTC
"make it faster" ... without concrete definition of what is making it slower, these are not useful bug reports. everything could be made faster and therefore better. =/ i appreciate how thoroughly you did research this, though, checking for variables such as icons on or not, number of applets, etc. the dashboard layer itself is constructed in a delayed fashion so as not to impede startup or use memory unnecessarily. it's created on the first access of it. the 1050x1680 resolution you are running at is probably why it takes as long as it does to create as that's how big a widget must be created and then pushed to screen. i'm running 1440x900 here and it does pop-up the second time and on in about .3s or maybe even less. the first time it takes a couple of seconds, yes. i'm not comfortable, however, with creating it on startup due the slowness it would induce and additional memory it would take even if never used (particularly on multi-screen systems) Joe: have you make this test with debug symbol or did you compile it with some optimization flag? Aaron: I have no problem with having a slow first initialization, but for some reason, I don't get any speed up on subsequant initializations. I confirmed this a little bit more scientifically by enabling the second hand on the analogue clock. When initializing the dashboard, the second hand freezes, and when the dashboard comes up again, the second hand jumps about 3 seconds. As for this being related to resolution, I did see a speedup when lowering my display resolution to 1400x1050 to about 2 seconds per initialization, but still no dice on a fast second initialization. Perhaps there is a caching problem on my configuration? Neither plasma's rss or vss changes appreciably between startup and after 1st dashboard initialization. I'm working on getting oprofile setup on my system so I can see a bit better where things are getting hung up. FineX: My build isn't debug enabled, and my cflags are pretty standard: -march=athlon64 -Os. hm.. i'm running kde4 on an athlon 64 here as well (3200+ iirc) and at 1450x900 res it's pretty much instant. sometimes on first show it takes up to 2 seconds, but sometimes it's also pretty instant on first show. if you do get oprofile output, that would be perfect. interesting to see what is happening there. thanks =) (Off Topic) Aaron: one interesting thing should be that developers could test KDE even on old hardware :-) now that binary packages are available this is more likely to happen. i do run it on my 1.8Ghz single core laptop, and will eventually get it on the eeepc here, but.. yeah.. testing labs don't abound. Well I'm leaning toward this being a possible xorg bug on my setup. Before I dug into devining oprofile output, I tried disabling composite in xorg.conf, and the activation of the dashboard performed as expected, slow the first time, and nearly instantly there after, minus the translucent grey background layer. My first oprofile output seems to suggest that a lot of time is being spent in libpixman.so when I start the profiling, activate and deactivate the dashboard repeatedly several times. and then deactivate the profiling and dump the system wide report. I did control against a profile without much going on (one konq window sitting open), and libpixman was substantially lower on the list. I'm now rebuilding big chunks of xorg (libXcomposite, libpixman, xorg-server), qt, kdelibs and kdebase with debuging enabled so oprofile can show me some more detail. As for my xorg setup: xorg-server-1.4.0.90 (marked ~amd64 "unstable" on gentoo) libXcomposite-0.4 pixman-0.9.6 Not completely on topic, but I don't find it too off topic either so I'll post it here. On my system the dashboard view is "too fast" (in my opinion of course), it doesn't give you the smooth feeling. Rather it feels like a slap in the face. The fade out is rather pleasant though. I have composite for KWin enabled. (Strange enough, I use an old nvidia driver). Created attachment 23095 [details]
Opreport dump of 1 initialization of the dashboard.
I created this oprofile output with: 'opreport --symbols' to create a system
wide profile of one dashboard initialization & return to desktop. As you can
see some 65% of the active cycyles is spent in libpixman-0.9.6.so, in the
symbol fbFetch_x8r8g8b8. Subsequant individual initialization of the dashboard
look nearly identical under oprofile.
If someone could create a similar oprofile report I could compare with to see
if this is in fact a bug with libpixman being slow, or something else.
I have nearly the same performance problem, located in libpixman, when some text is scrolling in konsole. Here is oprofile output samples % app name symbol name 765627 60.0509 libpixman-1.so.0.9.6 (no symbols) 83998 6.5883 libc-2.7.so (no symbols) 74273 5.8255 vmlinux-2.6.24-rc7-git5-2-pae.gz (no symbols) 71182 5.5831 libQtGui.so.4.3.3 (no symbols) 49676 3.8963 libkdeinit4_konsole.so (no symbols) 49345 3.8703 Xorg (no symbols) 24265 1.9032 firefox-bin (no symbols) 18538 1.4540 libfb.so (no symbols) 17367 1.3622 libQtCore.so.4.3.3 (no symbols) 16404 1.2866 libxaa.so (no symbols) 10529 0.8258 libmozjs.so (no symbols) 10405 0.8161 nv_drv.so (no symbols) 7751 0.6079 xfs (no symbols) 7264 0.5697 oprofiled (no symbols) 7063 0.5540 libxpcom_core.so (no symbols) > I have nearly the same performance problem, located in libpixman, when some text is scrolling in konsole. This is a known problem which appears to be specific to NVidia graphics - http://bugs.kde.org/show_bug.cgi?id=155174 . In the bug reporter's case the problem only occurred when using bitmap fonts. I have the same problem as Joe Kowalski CPU: Core 2, speed 1826 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 samples % image name app name symbol name 52944 68.4146 libpixman-1.so.0.9.6 libpixman-1.so.0.9.6 (no symbols) 12737 16.4588 no-vmlinux no-vmlinux (no symbols) 3716 4.8018 libc-2.7.so libc-2.7.so (no symbols) 2092 2.7033 nvidia_drv.so nvidia_drv.so (no symbols) 1462 1.8892 libQtCore.so.4.3.3 libQtCore.so.4.3.3 (no symbols) 1339 1.7303 libQtGui.so.4.3.3 libQtGui.so.4.3.3 (no symbols) 945 1.2211 oprofiled oprofiled (no symbols) 416 0.5376 libkdecore.so.5.1.0 libkdecore.so.5.1.0 (no symbols) 392 0.5065 Xorg Xorg (no symbols) 141 0.1822 librt-2.7.so librt-2.7.so (no symbols) 116 0.1499 bash bash (no symbols) I'm using nvidia-drivers-169.09 screen resolution 1280x800 so this comes down to x.org and/or specific x.org drivers just sucking at doing what we need it to. there's really nothing much we can do about this in plasma, other than disable the dashboard feature so that you can't see the problem (nor access the feature) which is obviously a bit wrong headed ;) i'm following a general "no upstream bugs" policy in plasma's BRs these days so as to keep our list of issues actually focused and possible to fix. *** Bug 162171 has been marked as a duplicate of this bug. *** *** Bug 172418 has been marked as a duplicate of this bug. *** The latest nvidia drivers (180.11 beta) seem to have this fixed. The dashboard appears nearly instantly now after the first initialization. Hello, I'm experiencing the same problem specified with the poster. I hit the shortcut to bring out the dashboard, then I have to wait for about 6 seconds for it to appear. This happens every time, not only the first time. I'm on kde 4.2 on kubuntu 8.10. Linux vaio 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux Using fglrx: OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Mobility Radeon HD 3650 OpenGL version string: 2.1.8201 Release This happens in both cases, when compositing in on or off. Any ideas? Thanks. P.S. This never used to happen on kde 4.1.4. -Nash |