Version: (using Devel) Installed from: Compiled sources I tried to delete my thumbnails dir (i could have deleted the dir, but i tried with the files in it) So in dolphin i had preview enabled, in thumbnailsfolder large were about 4500 files in folder normal were about 19000 Deleting the 4500 files gave me a nearly unrespondable kde, i tried switching to a terminal, but did not work, i tried Ctrl Alt del, but did not work, even ssh from my laptop did not work. To reproduce this i tried with the 19000 files. I let it run like is, and it keeps running, but dolphin takes about 100% CPU, nepumukservices 68%, rest is for kwin and so on. Bug appears as follows: 1. enable preview in dolphin 2. mark all files with Ctrl+A 3. right click "delete" (not move to trash) 4. notification pops up for deleting files 5. notification says "finish" after short time 6. dolphin and nepumukservices take all CPU making kde nearly unresponsible Now, after about 20 minutes cpu load still there. 7. kde runs, but not usable
Uhhh, forgot to mention version: KDE 4.2 RC (4.1.96)
I just commited a patch to the filewatch service making it handle everything in a different thread. This fixes bug #162932. It also solves the dolphin problem mentioned here. But cpu load will still go up in the service since all the metadata of all the files has to be deleted separately (even if there is no metadata, a query has to be made for each of the files). Thus, I am not sure if this bug can be closed or if we have to wait for a solution of the high cpu load.
So with this patch cpu load is only for nepumukservices, and dolphin should not appear anymore at the top loaders? I think best would be to leave the bug open anyways, as cpu load will stay for really long time, and i think thats not good. But maybe should be moved to nepumukservices then if dolphin is responsible again.
Some performance improvements in this regard have also been done in kdelibs recently, which improve the performance for the Dolphin process -> I'd like to close this issue at least from a Dolphin perspective. @Sebastian: I've changed to product to 'Nepomuk' in the case you still want to track responses to this kind of issue.
there is no way around this: Nepomuk simply has to delete the metadata for deleted files and that takes a bit of CPU. It is already much better in KDE 4.4 due to Virtuoso's involvement.
*** Bug 194861 has been marked as a duplicate of this bug. ***
Attention: Rant ahead !!! Sorry, that i dont like answers like this. For me it sounds like "It has to be slow, so its no bug" ... Sorry for the comparision, but if Microsoft would have bugs like that and say things like that they would not become successfull like they are. If this does not work in a good time, it is a feature that has to stay unimplemented. Thats my opinion. If i need (exxageration ahead) the 48th mersenne prime number for a software to be live calculated, and it should be usable, this software will never have success. I know this single bug report is not the right place to put my frustation, but after using linux for many years now, and filing bugs, once there is the time you hear things like that to often "wontfix", "nobug" aaarrggh. Dont get me wrong, i will stay with linux and kde, as i like the philosophy, but I lose the motivation to file bugs, and nothing moves. I cant fix it myself (not enough knowedge), so i always thought filing bugs, helping others in forums and so on is a good participation, but filing bugs that dont get fixed is useless. Even i filed bugs with the exact patch that has to be reverted, and nothing happens (ok, that was a kernel bug, but all together its similar everywhere). Sorry for that rant, but i have to speak it out, that i can calm down.
@frank: I can understand your frustration. If you want we can leave this bug open and maybe at some point we will come up with ideas to improve the situation. Would that be a "solution" you could be more comfortable with?
Sorry, that i leave my frustation here, as kde was one of the projects i got only minor frustrtation from. Now i calmed down a bit, but its to late to write a long excuse. I only had to let get of some "steam" of all the years. Maybe we can talk about it later (gtif ... no god thanks i have 2 weeks free from next weekend :) )