GNOME Bugzilla – Bug 792335
Rate limit trash monitor updates
Last modified: 2018-05-02 19:41:41 UTC
Trash monitor queries info from gvfsd-trash after each file monitor change which can be problematic when too many changes happen in a short time. Let's rate limit the number of queries... I've already proposed a similar patch for Nautilus trash monitor: https://gitlab.gnome.org/GNOME/nautilus/merge_requests/57 This is part of my effort to reduce CPU load during mass changes of mounts, see also: https://bugzilla.gnome.org/show_bug.cgi?id=792331
Created attachment 366502 [details] [review] trash-monitor: Rate limit updates
I am ok with rate-limiting, but 5 seconds is ... an eternity. Can lower this down to at most 1 second ?
Review of attachment 366502 [details] [review]: can you shorten the limit ?
Sorry, I was sick. Thanks for the review. Sure, I can shorten the limit, although Nautilus has already merged it with 5 seconds without any objections. But if I am not mistaken, this is used only to set trash folder icon accordingly (empty/full). So I don't think that it is crucial problem when it will be delayed for 5 seconds in the worst case. But I have got a better idea in the meantime. It will be better to simply prevent g_file_query_info_async before we get a result for the previous call... so the trash daemon won't be overloaded and we will have the result as soon as possible. I will prepare a patch for it...
Created attachment 367481 [details] [review] trash-monitor: Rate limit updates Ok, I've finally only lowered the limit to 1 sec, because the suggestion from Comment 4 still allowing an unreasonable amount of queries...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/1010.