4 ms·
> these days, generating or decoding PNGs is the bottleneck almost nowhere Anecdotal, but I'm familiar with a system which spends ~50% of CPU cycles on PNG enc
by gred 3y ago
> these days, generating or decoding PNGs is the bottleneck almost nowhere
Anecdotal, but I'm familiar with a system which spends ~50% of CPU cycles on PNG encoding (most of which is actually spent in zlib compression).
The other approaches I've seen involve creating performance-focused forks of zlib (e.g. zlib-chromium and zlib-cloudflare). This has benefits beyond PNG encode / decode:
https://aws.amazon.com/blogs/opensource/improving-zlib-cloudflare-and-comparing-performance-with-other-zlib-forks/ https://aws.amazon.com/blogs/opensource/improving-zlib-cloud...
- Nyan 3y agoWhy not use fpnge?
- gred 3y agoIt's a Java system, so not quite so simple. Maybe it's worthwhile to create some Java bindings? Recent JDKs make it feasible to swap out the underlying zlib implementation, so swapping out zlib-madler with zlib-cloudflare or zlib-ng might provide the best cost/benefit.
- Nyan 3y agoSomeone made this: https://github.com/manticore-projects/fpng-java https://github.com/manticore-projects/fpng-java Replacing zlib might give you a few percentage points' worth of difference, whilst fpnge would likely be several times faster.
- gred 3y agoVery cool, thanks for the pointer! We might be able to run an internal test to check performance vs. a zlib replacement, but I think that AGPL license is going to be a showstopper for anything else...