I'm using version 5.13 on Arch Linux. Since plasma 5, krunner is slow to the degree that it has become nearly unusable in many ways. It was nice to get the history back, but currently, typing "dolp" results in krunner showing d[igi] (where digi is marked as selected. Very often, nothing happens when typing into krunner. I have to wait a looooong time. In KDE 4 krunner was always working immediately, so something was changed in a way that makes it worse. Reproducible: Sometimes Steps to Reproduce: 1. type something into krunner 2. 3. Actual Results: nothing Expected Results: matches Arch Linux, fully up to date
A thought: Could this be related to a dbus client blocking the system, or just not answering? There is some akonadi dbus client that is very, very dead.
No reaction to this? Even not running akonadi at all, krunner is as good as unusable here, and I have no clue as to why.
Interesting. Could you possibly gdb into krunner and provide a backtrace when it is processing the query? $ gdb --pid `pidof krunner` > thread apply all backtrace This will give us a better idea of what is going on inside.
I have exactly the same problem. When I begin to type in Krunner, it takes a really long time to show me results. I just know what's happening, but no why. Do this steps: - Launch the "System activity" window before launch Krunner (Ctrl-Esc) and add the column disk I/O read ("I/O Read") and order the list by "I/O read" column - Launch KRunner and proceed as always to look something in the Krunner window. In my case, KRunner is on top of the I/O reads, taking about 3.250K/s for the time Krunner is "hanged". Finally, Baloo appears some seconds on top of the list, and then Krunner is operative again. So, in my case, Krunner is taking a lot of time on reading something from hard disk. This only happen first time I search for something in Krunner, so maybe is a bad Baloo optimization.
Likely, the problem is with some plugin, I'm just not sure which yet.
I had the same symptoms with the bookmarks plugin. Even if the plugin is not enabled, it will be loaded and prepared when something is typed into the search box after launch. My default browser is Firefox and preparing Firefox bookmarks causes krunner to freeze for many seconds. It's interesting why that plugin finds the Firefox profile and does something with it even though the plugin is not enabled and takes a long time doing that. Checked that this initial delay reduced a lot after removing plasma-runner-bookmarks.desktop from [prefix]/share/kservices5 so that the plugin could not be found. After this initial freeze, krunner remains quite responsive whenever anything is typed (if it doesn't crash or quit and automatically restart, which sometimes happens). plasma 5.5.3, KF 5.18 and Qt 5.5.1.
Is this still an issue in Plasma 5.6? We significantly improved performance there. While it can still take a split second for results to appear, typing in the text field is no longer delayed and laggy.
I think this issue is with some plugins. One of the worst is "documents", which I have had disabled for a long time to make krunner usable. Just tested, and it is still removing all signs of responsiveness when typing in krunner. .-- Kindly, Anders torsdag den 21. april 2016 19.38.14 CEST skrev du: > https://bugs.kde.org/show_bug.cgi?id=352785 > > Kai Uwe Broulik <kde@privat.broulik.de> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|UNCONFIRMED |NEEDSINFO > CC| |kde@privat.broulik.de > > --- Comment #7 from Kai Uwe Broulik <kde@privat.broulik.de> --- > Is this still an issue in Plasma 5.6? We significantly improved performance > there. While it can still take a split second for results to appear, typing > in the text field is no longer delayed and laggy.
I've tested all plugins on 5.6.3 and those are causing hangs and crashes as described: Audio, document, folder, image, video - all of these have "runner which searches through files, emails and contacts" as description. FYI, I've got a fairly large home (360G) on a btrfs raid-1, spinning, not ssd, and several network mounted drives (but they are excluded from indexing). my baloo index is quite big too: 4,1G .local/share/baloo/
By the way, 'type to search' in kickoff and 'application dashboard' plasmoid (if 'extend search to files' is activated) present same annoyances.
In KDE 4: - krunner was ALWAYS available, there was NEVER delay before the window showed up. NEVER swapped out. - krunner displayed available results first, NEVER waiting for <something broken> to finish. In KDE 5: - there is OFTEN delay before the window shows. Swapped out. - typing in the window rarely results in immediate results.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!