I know the crate is specifically for multi-threaded encoding/decoding.
I have managed to get sub millisecond encoding per image for my use case of encoding hundreds of small png files concurrently, and I would like to use mtpng to have low level control over Indexed pngs with transparency.
However, server side I do not want to use many threads on each request. Throughput of the server is more important, not time per request, so I think using the current thread would be the best way to do this.
I have looked at the code to see how easy it would be to have rayon as a default (optional) dependency, and be able to add default-features=false. However, I dont understand the code enough to remove the multithreading part in encoder.rs.
Also Im not even sure there would be a significant performance gain over
let pool = rayon::ThreadPoolBuilder::new().num_threads(1).build().unwrap();
(except that creating a thread pool per request seems like a bad idea)
I'd like to get feedback on this, also it could be useful for the WASM issue #13
I know the crate is specifically for multi-threaded encoding/decoding.
I have managed to get sub millisecond encoding per image for my use case of encoding hundreds of small png files concurrently, and I would like to use mtpng to have low level control over Indexed pngs with transparency.
However, server side I do not want to use many threads on each request. Throughput of the server is more important, not time per request, so I think using the current thread would be the best way to do this.
I have looked at the code to see how easy it would be to have rayon as a default (optional) dependency, and be able to add default-features=false. However, I dont understand the code enough to remove the multithreading part in encoder.rs.
Also Im not even sure there would be a significant performance gain over
let pool = rayon::ThreadPoolBuilder::new().num_threads(1).build().unwrap();
(except that creating a thread pool per request seems like a bad idea)
I'd like to get feedback on this, also it could be useful for the WASM issue #13