zune-jpeg 1.5x slower than libjpeg-turbo on the attached image about zune-jpeg HOT 4 OPEN

Hello, sorry for a late reply

Apparently Github doesn't send emails any more

Let me look into it

from zune-jpeg.

Initial findings

This is an interesting case.

Benchmarks on my machine
Amd Ryzen 4500U

And the function i.e decode_mcu_block is heavily optimized.

The issue I think is that

1. The image is quite detailed, it means we have to deal with a lot of data, so short paths the library tries to exploit do not work.

2. Because these short paths do not work, we end up doing more work than what libjpeg-turbo does, (e.g we do more work in IDCT in hopes that we can exploit that most blocks consist of a row of zeroes).

3. We have some extra optimizations in decode_mcu_block that may be a pessimization for this type of image, i.e we have one extra branch per decoded value which may be a culprit of branch mispredictions

from zune-jpeg.

After checking on this, the issue is that optimizations that work in other images become pessimizations for this particular image.

Due to the nature of this image, it remains an edge case and I do not see any issue in giving it a high priority.

But I would still like to add it to the benchmark samples to see if maybe I might optimize the library to handle such cases.

Closing this due to the above reasons, Feel free to open it if any need arises

from zune-jpeg.

High memory usage is the culprit.

Re-opening this

from zune-jpeg.