Currently dolphin's trash system feels incredibly sluggish by default on many distributions. I feel this has a negative impact on a lot of new users -- and potentially unknowing experienced users -- in regards to their feeling about dolphin and KDE in general. I think this situation could be remedied a couple of different ways: - Switch defaults so that dolphin operates on a 30 day time frame cleanup, rather than a disk % - Change the limiting system to be handed by a background job; so effectively when you delete a file, it would be immediately moved, but then in the background, something would be tasked with cleanup the necessary amount of disk space from the trash soon after. This would allow the user to get instant feedback, and the enforcement of the disk space limit would then happen seamlessly in the background, without any impact to user experience.
(In reply to Wyatt Childers from comment #0) > Currently dolphin's trash system feels incredibly sluggish by default on > many distributions. I feel this has a negative impact on a lot of new users > -- and potentially unknowing experienced users -- in regards to their > feeling about dolphin and KDE in general. > > I think this situation could be remedied a couple of different ways: > - Switch defaults so that dolphin operates on a 30 day time frame cleanup, > rather than a disk % > - Change the limiting system to be handed by a background job; so > effectively when you delete a file, it would be immediately moved, but then > in the background, something would be tasked with cleanup the necessary > amount of disk space from the trash soon after. This would allow the user to > get instant feedback, and the enforcement of the disk space limit would then > happen seamlessly in the background, without any impact to user experience. Actually upon further testing, it seems the time based trash enforcement is subject to the same performance penalties, and could benefit from the proposed changes to disk space limiting.
Oddly I've only just recently (last week or so) noticed trashing being slow - 1-2 seconds trashing small (<1MB) files. Removing the size limit in Dolphin's settings fixes this making trashing instantaneous.
Confirmed in latest release (17.12.2) and also current master (18.03.70).
I noticed this too. In my case deleting files had several seconds delay, but subsequent deletion was instantaneous. I suppose delay is caused by calculation of current trash size to decide whether it needs cleaning before adding new content. While trash contents listing is cached in OS, it takes way less time to recalculate occupied space for next deletion, but once it gets squeezed out of cache moving content to trash needs to reread disk content. One more thing that corroborates this theory: recently calculation of occupied space got broken in my system ( https://bugs.kde.org/show_bug.cgi?id=383324#c2 ), now dolphin shows free space of trash equal to its size limit regardless of contents. And now moving content to trash is always instantaneous for me. If my assumption is correct, this bug should not be noticeable for users with trash on SSD. My $HOME is located on HDD, so reading thousands of files/dirs of trash listing from storage should take seconds. Wyatt, Huon are your trash located on HDD or SSD?
> Wyatt, Huon are your trash located on HDD or SSD? I am on an NVMe SSD. I just tested again: First deletion: ~20s Second deletion: ~2.5s Apart from that, I think your theory is solid. Something about the calculation of trash size, which gets cached, or skipped entirely if trash size limit is disabled. I had a quick look in Dolphin's code for where this might be happening, but being unfamiliar with the code base I couldn't find it (perhaps it's in KF5 somewhere?)
(In reply to Huon from comment #5) > First deletion: ~20s Sorry for spam, but this should read ~10s.
(In reply to Alexander Meshcheryakov from comment #4) > I noticed this too. In my case deleting files had several seconds delay, but > subsequent deletion was instantaneous. I suppose delay is caused by > calculation of current trash size to decide whether it needs cleaning before > adding new content. While trash contents listing is cached in OS, it takes > way less time to recalculate occupied space for next deletion, but once it > gets squeezed out of cache moving content to trash needs to reread disk > content. > > One more thing that corroborates this theory: recently calculation of > occupied space got broken in my system ( > https://bugs.kde.org/show_bug.cgi?id=383324#c2 ), now dolphin shows free > space of trash equal to its size limit regardless of contents. And now > moving content to trash is always instantaneous for me. > > If my assumption is correct, this bug should not be noticeable for users > with trash on SSD. My $HOME is located on HDD, so reading thousands of > files/dirs of trash listing from storage should take seconds. > > Wyatt, Huon are your trash located on HDD or SSD? BTRFS SSD here
Try KIO 5.51.
author Alexander Volkov <a.volkov@rusbitech.ru> 2018-09-06 21:42:57 (GMT) committer Alexander Volkov <a.volkov@rusbitech.ru> 2018-09-06 21:43:26 (GMT) commit 9d682612de4691a13daa69d02816d23b6a77a285 (patch) tree 33db7bb2252fd83ce8849aa8551a97543cd10710 parent 820f622e86bb0b7d44a39a3f90f84c99736b30c7 (diff) trash: Fix directorysizes cache parsing Summary: Entries in this file have the following format: [size] [mtime] [percent-encoded-directory-name] , and TrashSizeCache::add() writes them correctly, but TrashSizeCache::calculateSize() reads [mtime] as [size] and vice versa. Reviewers: #frameworks, dfaure Reviewed By: dfaure Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D15317
Just for the record, this looks like a regression for this old bug: https://bugs.kde.org/show_bug.cgi?id=179348