Description of problem: press alt-f2, wait 6-7 seconds for krunner dialog to show up Version-Release number of selected component (if applicable): kde-workspace-4.4.0-2.fc12.i686 soprano-2.4.0.1-1.fc12.i686 How reproducible: always Steps to Reproduce: 1. alt-f2 2. wait 3. krunner dialog shows up Actual results: 6-7 seconds Expected results: 0-2 seconds Additional info: This is on a 1.6GHz Atom, ASUS eeePC 1000he. On a quad-core x86_64 desktop I'm not seeing the delay. The theme is also different there. Performance was normal under KDE 4.3. I don't know how to debug what's going on once I hit alt-f2.
Could you try disabling krunner plugins to try to see if one of those are causing the problem? Once krunner is visible, click the "wrench" on the left and start unchecking things. Likely candidates include: bookmarks, nepomuk, recent documents, spell checker, techbase, web*
Just to be sure, I tried all 3 built-in themes on this machine and set CPU to 'low' under Appearance..Style..Fine Tuning and that wasn't it. I did hear the CPU fan kick in when testing, and watching under top it appears krunner takes 30% CPU for a couple seconds and it causes kcryptd to take about 70% for another 3-4 seconds (LUKS drive). I wonder if there's a new disk I/O pattern in 4.4.
Good call, Rex, it's definitely 'bookmarks'.
Created attachment 395791 [details] strace of krunner with bookmarks turned on Running strace with timing, I see: 0.000416 writev(3, [{"l\1\0\1\36\0\0\0\v\0\0\0\202\0\0\0\1\1o\0\20\0\0\0/MainApplication\0\0\0\0\0\0\0\0\6\1s\0\17\0\0\0org.kde.krunner\0\2\1s\0\32\0\0\0org.kde.KUniqueApplication\0\0\0\0\0\0\3\1s\0\v\0\0\0newInstance\0\0\0\0\0\10\1g\0\4ayay\0\0\0\0\0\0\0", 152}, {"\0\0\0\0\26\0\0\0\0\0\0\16/home/flowerpt\0\0\0\0", 30}], 2) = 182 0.001068 gettimeofday({1266949304, 639290}, NULL) = 0 0.000220 poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}]) 4.967767 read(3, "l\2\1\1\4\0\0\0C\4\0\0.\0\0\0\6\1s\0\6\0\0\0:1.149\0\0\5\1u\0\v\0\0\0\10\1g\0\1i\0\0\7\1s\0\5\0\0\0:1.91\0\0\0\0\0\0\0", 2048) = 68 IIRC, that's a dbus request it's waiting for. If I watch dbus, the main difference I'm seeing is a bunch of amarok requests: > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1214 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1215 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1218 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1220 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1223 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1226 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1229 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1231 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mpris.amarok'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1234 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.kde.kopete'" > > method call sender=:1.91 -> dest=org.freedesktop.DBus serial=1235 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch > > string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.kde.kopete'" > > method call sender=:1.5 -> dest=org.kde.knotify serial=700 path=/Notify; interface=org.kde.KNotify; member=event I'm not sure what to make of that.
err, "amarok and kopete", obviously.
This one should be better in 4.4.1, which we're going to get very soon, let's retest then.
This bug has been triaged Steven M. Parrish KDE & Packagekit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Ping? Does this still happen with 4.4.1?
Appears to be fixed with 4.4.1. I'm on a mildly faster machine now, but response is near-instantaneous, so that's probably not the reason.
Thanks.