User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.9) Gecko/20071106 Firefox/2.0.0.9 Build Identifier: Machines are going multicore, quad core is becoming common and in five years we'll probably have sixteen core machines. It would be good to use this: have thunar generate thumbnails in parallel. This is actually an advantage to having thumbnailer scripts too: the file-manager just needs to launch them to the background: no need for a parallel-implementation of each individual thumbnailer like would be required if it were daemon-based. I'm not sure if it's best to use all processors with a very high niceness, or use P-1 of them. Reproducible: Always
No idea if this is actually a good idea, because the priority of thumbnailing is low and most likely on a fast desktop reading from the disk takes longer.
*** Bug 7493 has been marked as a duplicate of this bug. ***
thunar loads only thumbnails that are in your view (which is very smart), there is no need for multicore(?), it will only strain the hdd more as well
I may be wrong here but I fear that opening a folder with say 100 different video files, and they too get thumbnails, would cause the machine to feel very sluggish if Tumbler started 12 processes all at once. I guess it could be "smart" about it and check if the files are on a local SSD or a HDD or a network attached storage and start $nproc/2 processes. It seems to me that the simpler solution is to just thumbnail one file at a time?
I've reported https://bugzilla.xfce.org/show_bug.cgi?id=7493 some years after this one (as indicated by the duplicate flag above). In Debian we carry a (quite naive) patch (https://sources.debian.org/src/tumbler/0.2.3-1/debian/patches/0001-multithread-using-the-number-of-processors-on-the-sy.patch/) and I don't think we had issue with it since it was enabled last year. I rather think it's more useful to be done with the work as soon as possible, and if there's a task which can be parallelized easily, then it's a good idea to do it (especially these days were CPU core number progresses faster than raw power). There might be an issue if a thumbnailer is broken and loops, but the exact same thing would happen whichever number of CPU cores is available (and it will actually be worse if the CPU is monocore). I think we had some reports here and there about videos thumbnailers stuck at 100% for a while, and it would be worth having a timeout, I guess. As I said in #7493, it might make sense to use #CPU -1 or #CPU/2 or whatever. For now I think we're fine with all of them.
-- 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/tumbler/-/issues/1. 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