Here is some performance measurement of the trunk version of Juicy.Pixels.
This is a simple benchmark considering two operations :
- Reading a 1360×1312 PNG image and saving it as a JPG.
- Reading a 4928×3264 JPG image and saving it as a PNG.
Both images are the “huge” test images present in the JuicyPixel repository.
- Test machine : Core i5 M520@2.40Ghz
- OS : Windows7 x64
- GHC : 7.4.2
- The energy mode is set as “best performances”.
The imagemagick performance as been measured with the command “convert” repeated 20 times with the time result are below :
PNG -> JPG Avg: 306.3059ms Min: 290.6701ms Max: 327.0791ms JPG -> PNG Avg: 3668.5218ms Min: 3637.5323ms Max: 3741.9981ms
The Benchmarking of Juicy.Pixels is done using the Criterion library. In 20 runs, the code is the following :
jpegToPng :: IO () jpegToPng = do img <- readImage "tests/jpeg/huge.jpg" case img of Left err -> putStrLn err Right i -> savePngImage "huge.png" i pngToJpeg :: IO () pngToJpeg = do img <- readImage "tests/pngsuite/huge.png" case img of Left err -> putStrLn err Right i -> saveJpgImage 50 "huge.jpg" i
And the results :
benchmarking trad/JPG -> PNG collecting 12 samples, 1 iterations each, in estimated 158.6611 s mean: 16.40936 s, lb 15.57981 s, ub 17.18032 s, ci 0.950 std dev: 1.477429 s, lb 1.199743 s, ub 1.949199 s, ci 0.950 variance introduced by outliers: 31.549% variance is moderately inflated by outliers benchmarking trad/PNG -> JPG collecting 12 samples, 1 iterations each, in estimated 20.88119 s mean: 1.091229 s, lb 1.083062 s, ub 1.097646 s, ci 0.950 std dev: 13.40252 ms, lb 9.745841 ms, ub 17.60697 ms, ci 0.950 variance introduced by outliers: 7.639% variance is slightly inflated by outliers
We can see that we are roughly at 4x the speed of imagemagick C implementation. Thats reasonable, but I’m curious what the improvement of the new code generator of GHC 7.6 would bring on the performance side.