Hacker News Reader

Comment by Ono-Sendai | Hacker News Reader

Testing with Release config (full program optimisation):

  testing loading image: D:\art\cryptovoxels\ortho overview.png
  libSPNG decode took 0.1901 s
  libPNG decode took  0.2069 s

  testing loading image: D:\art\skymodel2_test3\top2 CPU.png
  libSPNG decode took 0.007862 s
  libPNG decode took  0.007801 s

View on HN

This is what I use for benchmarking: https://github.com/libspng/spngt, my platform is Debian 10, GCC 8.3.0 with -O3 on an i5-4670. I use -SPNG_SSE=2 because that targets SSE2 instead of SSSE3, this matches the Debian build of libpng, both are linked against zlib-ng. The results I get for medium_rgb(a)8.png and large_palette.png are the results on the charts.

What version of LibPNG are you comparing against? I am using LibPNG 1.635. Note that recent versions of LibPNG have some SSE optimisations contributed from Intel.

I'm using 1.6.36, the most obvious speedups should come from RGBA 8-bit PNG's, that codepath doesn't rely on compiler optimizations.

To speculate on these results a little:

I'd say the performance in general with Libspng and Libpng is pretty similar. The apparent greater speed of Libspng in the RelWithDebInfo build may be due to the use of the inline keyword, which libpng doesn't use. However once full program optimisation is enabled, and functions are inlined across translation units etc.., the code comes out pretty similar and hence has performance parity.

Reply on news.ycombinator.com