You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The image resizing routines in image seem to be really slow compared to the competition.
For example, fast_image_resize crate benchmarks show that image is 5x slower than libvips and fast_image_resize's fallback implementation, and 20x slower than fast_image_resize's AVX2 implementation. It also does runtime CPU feature detection.
I have run the RGB benchmarks locally against image v0.25.1 to reproduce the results, and I can confirm that they are accurate on my machine - the performance gap is real:
It's tempting to just use fast_image_resize - or at least its fallback implementation, and perhaps make all the unsafe SIMD intrinsics an opt-in feature like we did with rav1e and its nasm feature.
The drawback is that there seems to be some unsafe code in the fallback implementation that would need to be audited. Also, it seems the crate has never been fuzzed.
The image resizing routines in
image
seem to be really slow compared to the competition.For example,
fast_image_resize
crate benchmarks show thatimage
is 5x slower thanlibvips
andfast_image_resize
's fallback implementation, and 20x slower thanfast_image_resize
's AVX2 implementation. It also does runtime CPU feature detection.I have run the RGB benchmarks locally against
image
v0.25.1 to reproduce the results, and I can confirm that they are accurate on my machine - the performance gap is real:The text was updated successfully, but these errors were encountered: