Version: (using Devel) Compiler: gcc OS: Linux Installed from: Compiled sources Currently When I try to move large numbers of files dolphin blocks for some time. tested by moving ~800 files (from a folder with ~2000 files) totaling ~200 Mb to another folder with ~1000 files Firstly what usually happens is that dolphin blocks and maxes out one of my cores. Then it starts responding and the files apparently are moved. immediately afterwards nepomuk maxes out a core (but doesn't block dolphin) and eventually returns to sleep. I also tried with fewer files and more files than specified above. The time that dolphin stays blocked seems dependent more on the number of files than total size of the files. This effect is more reproducible when moving files from folders with a lot of files to folders with lots of files. If one is doing two file operations e.g. copying a large 300Mb file and also copying lots of files similar to the scenario above, the 300Mb operation also blocks (i.e. it completely stops as nepomuk and dolphin max out a core each at the same time). One other thing to note is that I'm using the redland backend and I've heard that is notoriously slow in comparison to sesame. Could that be causing these problems? Please let me know if there is any more information that you require.
Ok, I think here are two different issues. First to the Dolphin side (which I do not know much of): I heard about some bugfix to Dolphin/kio, not sure if that has been backported to 4.1, which should speed up file movement. (Hopefully someone else nows more). I know more about CPU usage of Nepomuk at that time. When moving files Nepomuk tries to move the Data it has about the files too. For that it has to "look" if there is any data for the files you moved. That takes some time for every file. But that should not block Dolphin "only" use some CPU time. And yes with Redland this is much slower. (on my System to check if there are Infos for a file takes a few ms each with sesame2, while with Redland it is more like 0.5 - 2 seconds.) You could try to disable Nepomuk in the KDE settings and check if that also changes the Dolphin blocking (which should not be caused by Nepomuk).
Thanks Daniel for clarifying the Nepomuk part, I can give some details for the Dolphin part: When selecting a lot of files in Dolphin while the Information Panel is open, the information panel asks Nepomuk for the rating + tags of each file. Especially with the Redland backend this is extremely slow and Dolphin got blocked several seconds. But even with another backend, a blocking is possible when having a cold disk cache. After discussing this with Sebastian Trüg (= Nepomuk maintainer) we came to the conclusion that we move this query for the metadata into a separate thread, so that Dolphin does not get blocked anymore. The fix was not trivial and hence not backported to KDE 4.1.x, but in KDE 4.2 Dolphin is never blocked anymore because of Nepomuk. I've set this issue to FIXED, please feel free to reopen this issue if there are still performance issue in combination with Nepomuk. Thanks!
Ok, I have disabled nepomuk, However the problem still occurs. Dolphin still blocks for a while before initiating the move and still maxes one cpu doing something. Nepomuk cpu usage, as far as I could tell would only occur after the files were moved and didn't block dolphin.
Hmm... tried the latest revision and the problem seems to be gone, in dolphin at least.
Thanks Tiago for testing :-)
Could you have a second look at this bug? In 4.1.86 (using unofficial Debian packages from kde42.debian.net at version 4:4.1.86+svn902162-0r1), kio_trash maxes out one core when moving multiple directories to the trash. To reproduce, select multiple directories in Dolphin and press the Delete key. It just feels way to slow for such a simple operation given that I'm running an recent hardware.
Reopening the bug...for..Georg's sake :)
I'm having the exact same "move problem" on Suse. I just have one core to max out so things get pretty slow. If I kill Nepomuk there is a speed improvement, still on the slow side but much, much better. A friend on KDE 4.2.0/Debian have the same problem with moving large number of files. tested on: Dolphin 1.2 (KDE 4.2.00 (KDE 4.2.0) "release 90.1", KDE:KDE4:Factory:Desktop / openSUSE_11.1)
I've added Sebastian (= Nepomuk maintainer) to CC.
On KDE 4.2 all operations on Nepomuk side are done async, too. Apart from that: if you are using the redland backend then I cannot give any support other than adding a warning in KDE 4.3 or simply making the sesame2 backend mandatory in kde 4.2.1. Debian does not package sesame2 since it depends on Java. You can check your backend via: "qdbus org.kde.NepomukStorage /nepomukstorage org.kde.nepomuk.Storage.usedSopranoBackend"
Thanks for the info! I was using the redland-backend. With redland disabled it is much faster. To test this bug try to move a couple of hundred megs of photos. (with redland enabled). Couldn't test with sesame2.
on suse, if you uninstall the redland backend and install sesame2 it automatically gets enabled. But you can't switch to it if you still have redland installed (sesame2 doesn't show up in sopranocmd).
if redland and sesame are installed, Nepomuk should automatically choose the latter. That does not happen on SuSE?
apparently not. It's not even listed if redland is installed. Remove redland and it magically shows up (despite not being found before).
*** Bug 184784 has been marked as a duplicate of this bug. ***
*** Bug 185883 has been marked as a duplicate of this bug. ***
I've verified moving of 500 files (flat hierarchy) with around 1,1 GiB here on trunk (enabled Nepomuk, enabled tooltips, enabled Information Panel). Dolphin is blocked for ~0.5 seconds in this case. I tried also to copy 2600 files (269 MiB) and the blocking increased to around < 1 second. I'm not sure how much room for improvements are left, but by reading through all the comments I'm unsure from which timespan you are talking. Does it block for several seconds in your case are is it in the range I'm talking (~ 0.5 seconds)? I think the goal should be at least < ~0.3 seconds...
I have not seen this behaviour recently, but that would say nothing as I did not explicitly try it out neither. The timespan on my computer when copy/pasting could use up several seconds (e.g. a very visible timespan) of "preparation time", wants to say time where kde is unresponsive and slow before the real copying starts.
Seems to be fixed in 4.4.1. Thanks.
Hi, Please confirm that this issue is still present in that latest stable KDE version. Thanx, Mark
Hi Mark, Thanks for looking into this. > Please confirm that this issue is still present in that latest stable KDE > version. Debian does not ship 4.5 yet and unfortunately I don't have the time to build from source. I'm afraid I can't help you with this at the moment. Regards, Georg
Using KDE 4.5.00 /opensuse 11.3 I cannot reproduce my problem, eg. 10-20 seconds of blocking in preparation of copying. Seems to be fixed for me.
Thanks to all for retesting - I've set this issue to FIXED for 4.5.