Image-rs open image speed

I'm trying to use image-rs to provide an image resizing service in my WebAPP

However, I have found it takes a quite long time(about 2secs) when I use image::open(path)

The binary file is built in Debug mode. Will adding --release tag help solve this problem?

Yes.

6 Likes

It's possible to override the profile configuration for specific packages in your own Cargo.toml. Note that this applies to specific packages, not their own dependency trees. So, for example, here's my own configuration for ensuring that any png decoding is fast in all build profiles:


[profile.test.package]
adler32.opt-level = 3
crc32fast.opt-level = 3
miniz_oxide.opt-level = 3
png.opt-level = 3
deflate.opt-level = 3

[profile.dev.package]
adler32.opt-level = 3
crc32fast.opt-level = 3
miniz_oxide.opt-level = 3
png.opt-level = 3
deflate.opt-level = 3

More information here: Profiles – The Cargo Book.

5 Likes

Thanks both,
By adding --release tag, opening delay reduced to a few milliseconds
But why is the difference so big?

Seeing 50x different is not uncommon at all. LLVM is really good at optimizing, and because of that Rust isn't all that careful about what it emits, since LLVM can clean it up. But that means that if the optimizer isn't running at all, the generated code is very slow.

3 Likes

Making code faster is computationally expensive task. During development it's common that every new run requires recompiling as the source code is changed since last compilation. In this case optimizations usually slow down the total compile+run cycle. But after released the code compiled once tends to keep running for a long time. In this case the benefits of fast code outweighs the one-shot cost of the optimization.

2 Likes

glad i stumbled on this too - recently using the image.rs crate and was wondering why it was so slow. :bulb: makes perfect sense in hind sight

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.