Hacker News Reader

Comment by Ono-Sendai | Hacker News Reader

Some performance tests decoding PNGs:

Platform: Windows 10, Visual Studio 2019, RelWithDebInfo config, Intel Core i7-8700K. Compiled with -DSPNG_SSE=3.

  testing loading image: D:\art\cryptovoxels\ortho overview.png (32-bit, large)
  libSPNG decode took 0.2221 s
  libPNG decode took  0.2373 s

  libSPNG decode took 0.2215 s
  libPNG decode took  0.2364 s


  testing loading image: D:\art\dof_test_output.png (32-bit)
  libSPNG decode took 0.01101 s
  libPNG decode took  0.01225 s

  libSPNG decode took 0.01096 s
  libPNG decode took  0.01205 s


  testing loading image: D:\art\skymodel2_test3\top2 CPU.png (24-bit)
  libSPNG decode took 0.008874 s
  libPNG decode took  0.009399 s

So Libspng seems slightly faster, but certainly not 35% faster, in these tests.

View on HN

As I'm guessing most people who have had to use libpng will agree, the biggest strength here is a less-byzantine API. As good as the PNG format is, the library API is kind of awful.

libpng does have simplified API (png_image*) since 1.6

Wow, this is amazing. I did not know about these new API functions. It makes using libpng much more pleasant. Thanks!

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

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.

Did you put it in a loop to eliminate startup time?

Yes, am showing minimum time from 10 runs.

Reply on news.ycombinator.com