--fast seems to only use one thread for most of the processing

shssoichiro / oxipng

Multithreaded PNG optimizer written in Rust

MIT License

2.95k stars 125 forks source link

--fast seems to only use one thread for most of the processing #609

Closed C0rn3j closed 6 months ago

C0rn3j commented 7 months ago

oxipng --fast --opt max even with --threads 10 uses one thread for the processing except for the small part at the very beginning, is this expected?

oxipng 9.0.0 on Arch Linux

andrews05 commented 7 months ago

Hi @C0rn3j, yes this is expected behaviour. See the description in the help:

Perform a fast compression evaluation of each enabled filter, followed by a single main
compression trial of the best result. Recommended if you have more filters enabled than
CPU cores.

It's also helpful if you're processing many files at once, but if you're just doing one file at a time and have plenty of CPU cores then you're probably best to leave it off.

C0rn3j commented 7 months ago

I got the impression that this would run small trials first and then just run whatever method worked the best on the small scale, with all cores.

So while it might have not been the best end result, it would be a reasonably fast result (x5 CPU time instead of x100 for just pure --zopfli).

Is there anything preventing from this running the final trial at max CPU?
I would prefer not having to parallelize this myself.

andrews05 commented 7 months ago

Neither libdeflate nor zopfli currently support parallelisation, so it's not possible to get any more speed out of it unfortunately.