Sanity check jpeg-decoder, wasm, 36-cycles / pixel?

I am using jpeg_decoder - Rust v 0.2.6, compiled to wasm.

I am not using web workers for concurrency.

I am timing the time it takes to decompress 1000 1024x1024 jpegs (after the data is already in a shared array buffer). This is taking ~ 12 seconds on a 2-3 ghz machine, or around 24-36 cpu cycles per pixel.

Does this sound about right performance wise? On one hand, 12 seconds for 1 GB of data feels slow, but 24-36 cpu cycles / pixel decompression doesn't sound too unreasonable.


It sounds reasonable. JPEG decoding benefits a lot from SIMD, but probably the WASM version doesn't get it.

1 Like

Interesting insight.

I decided to try it via the native in browser JS api for jpeg decoding (via creating an Image elemtn, then setting the img.src to a base 64 encoded data URL).

Turns out I can't figure out how to create Image elements in WebWorkers since they do not appear to have access to the dom.document object.

Can you do it via the Canvas API?

EDIT: I looked at it, and it is a mess. Maybe the best solution is to try and enable the SIMD extensions in wasm.

This is a wasm file that runs in Chrome on client machines (and I can not pass command line options to). Is there a way to enable SIMD from just JS/wasm land ?

I have not tried it myself, so take a look at this:

1 Like

I am not willing to put in the time to modify the jpeg library -- but thanks for sharing it. I was completely unaware that (1) wasm32 now has simd support and (2) Rust has support for it. Might rewrite some internal matrix ops with this.

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.