Created attachment 7472 Thunar slow multiple files renaming Slow multiple files renaming in Thunar 1.6.11 Steps to reproduce: 1. Create 2000 small .png files in one directory 2. Select all and choose "rename" from context menu. 3. Choose number format "0001, 0002", start with 1, "number-text", text - ".png" 4. Watch how slow that is and processor time consuming (Thunar up to 70% CPU) Check my screencast for details. I'm on Debian 9 Stretch.
Forgot to mention in the steps switching to the compact list view before renaming.
Here (Core i5 4th gen w/ SSD) it uses all four cores and takes about 30 seconds to complete the bulk rename. I can say it's far from optimal, probably renaming via shell would be much faster, but I would not say it's terribly slow. Yes, there's room for improvement, probably the ui updates while renaming causes the slowdown.
If you get out of the folder where the files are renamed the process is much, much faster. It seems that what's slowing down is redrawing the file list for every update in file names. Thunar has the same behavior when deleting files. If you delete a few hundred files it is very slow. Thunar hogs resources and becomes unresponsive. If you leave the directory containing the files (which can be very sluggish to do when Thunar is busy deleting) the file deletion jumps up in speed directly as you are out of the folder, finishing the task almost instantly.
If I connect to the same folder via sftp, eg put: > sftp://schwinn@localhost/home/schwinn/software/thunar_test/slowFileRenaming-Bug14059 into the address bar instead of > /home/schwinn/software/thunar_test/slowFileRenaming-Bug14059/ Than my CPU during renaming is only on ~60% for ~13sec instead on ~350% for ~30sec Thats why I suppose that file / folder monitors cause the problem by triggering a view update for each file (file / folder monitors are not available via sftp connections)
(In reply to alexxcons from comment #4) > Thats why I suppose that file / folder monitors cause the problem by > triggering a view update for each file > (file / folder monitors are not available via sftp connections) Makes sense. With your changes in Bug 15704, is it possible now to temporarily disable monitors while renaming?
> With your changes in Bug 15704, is it possible now to temporarily disable monitors while renaming? So far I only did some experiments with g_file_monitor_set_rate_limit on the folder monitor, but that did not help. Each ThunarFile as well has a monitor .... wonder if we realy need that double-monitoring. Have to further debug, and see if it helps to disable this monitor. If the monitor of ThunarFile is to blame: disable/enable the monitor is possible (not related to Bug 15704), though I dont think that would be a good solution, since "rename" probably is only one of multiple operations which cause the monitor to trigger, and to eat CPU.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org'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.xfce.org/xfce/thunar/-/issues/182. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev