Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about Blog Post benchmarks #85

Open
rajasagashe opened this issue Dec 11, 2020 · 1 comment
Open

Question about Blog Post benchmarks #85

rajasagashe opened this issue Dec 11, 2020 · 1 comment

Comments

@rajasagashe
Copy link

Hello, thanks for writing this excellent blog post https://medium.com/criteo-labs/boosting-image-processing-performance-from-imagemagick-to-libvips-268cc3451d55.

The blog post mentions that JVips gives significant improvement over image magick: "up to x8 on JPEGs and x2.3 on PNGs with 8 threads". However, the graph is a bit vague and doesn't specify what's being measured.

Is this improvement in processing time for a single image where libvips is able to use the 8 threads to process it faster? Or does it refer to throughput where each thread is processing an image on its own as shown inExecutorServiceExample?

@dbouron
Copy link
Contributor

dbouron commented Dec 24, 2020

Hello,

Thanks for reading.

The "x8 on JPEGs and x2.3 on PNGs with 8 threads" refers to a simple benchmark which compares JMagick and JVips.
It reads a 1920x1080 image, resize it (ImageScale for JMagick and thumbnail for JVips) and write the output in a buffer.

The graph measured the image processing time spent in the processing pool. It includes at least one operation (resizing) and some others operations may be applied (padding, cropping). Thus, the improvement that you can observe in the graph is in production with a high image traffic.

The ExecutorServiceExample is an example to show how avoid crash when using an executor (see.also.: #42)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants