! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Generate thumbnails in parallel


Description Erlend Davidson 2007-11-29 14:27:09 CET
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv: Gecko/20071106 Firefox/
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
Comment 1 Nick Schermer editbugs 2012-09-26 16:31:31 CEST
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.
Comment 2 Lionel Le Folgoc 2012-12-13 18:12:36 CET
*** Bug 7493 has been marked as a duplicate of this bug. ***
Comment 3 kuko 2019-01-22 12:29:32 CET
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
Comment 4 Öyvind Saether 2019-06-20 13:55:33 CEST
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?
Comment 5 Yves-Alexis Perez editbugs 2019-06-20 14:05:14 CEST
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.
Comment 6 Git Bot editbugs 2020-05-25 23:16:46 CEST
-- 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

Bug #3703

Reported by:
Erlend Davidson
Reported on: 2007-11-29
Last modified on: 2020-05-25
Duplicates (1):


Jannis Pohlmann
CC List:
3 users




Additional information