Skip to content

Juicy.Pixels performances

January 27, 2013

Here is some performance measurement of the trunk version of Juicy.Pixels.

Benchmarks

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”.

Imagemagick benchmarking

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

Juicy.Pixels benchmarking

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

Conclusion

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.

About these ads

From → Uncategorized

3 Comments
  1. I’m thanking you again for this great library. However, I’m somehow not comfortable with the idea of being ~4x slower than the “equivalent” C library. I’m really thinking something better can be achieved, now sure how though. I’ll try to investigate this soon!

    • To be fair, I was exepecting a x3 slowdown in regard to the C version, but I don’t really know what to do next. I’ve removed all monadic combinators and use direct recursion (which force arguments to be strict) for the inner loops. Maybe an output to a file using handle would be quicker, but I don’t want to loose the in-memory serialization which would be tremendously useful for web services.

      If you want to try to improve performances, be sure to get the trunk from github, as it contain the benchmarked version, and if you want to exchange (maybe in french) on this subject don’t hesitate to drop me a mail :)

      • I’m doing some profiling, I’ll see where that leads — if anything good comes out of my investigation, I’ll shoot you a mail to let you know and discuss further improvements :-)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: