Provided benchmark correct only for small files

[laszbalo]

I have ran your benchmark with medium/large size images and got completely different result.
According to my measurements, imagemagick-native was 1.5/3 times slower than imagemagick.

I have tested it with this photo.

I downloaded the "Standard 4:3" and "HD 16:9" sizes of the same photo.

Here are my results:

1. Provided test.jpg, 6.9 kB, 58x66
   imagemagick: 15.23ms per iteration
   imagemagick-native: 1.45ms per iteration
   Winner: imagemagick-native is 1050% faster
2. Above wallpaper, standard, 139.3 kB, 800x600
   imagemagick: 33.06ms per iteration
   imagemagick-native: 47.16ms per iteration
   Winner: imagemagick is 142% faster
3. Above wallpaper, standard, 1.0 MB, 2800x2100
   imagemagick: 248ms per iteration
   imagemagick-native: 556.9ms per iteration
   Winner: imagemagick is 224% faster
4. Above wallpaper, HD,153.9 kB, 960x540
   imagemagick: 37.4ms per iteration
   imagemagick-native: 48.59ms per iteration
   Winner: imagemagick is 129% faster
5. Above wallpaper, HD, 965.4 kB, 2880x1620
   imagemagick: 178.96ms per iteration
   imagemagick-native: 440.14ms per iteration
   Winner: imagemagick is 254% faster

As far as I can tell, using imagmagick-native makes sense, only with small files.
What is your input on this?

With thanks,
Laszlo

[paolochiodi]

As the maintainer of both https://github.com/paolochiodi/resizer and https://github.com/blomming/image-server I'm really interested in this issue and in performance problems with image magick in general.
I also spent some time researching into that, so I'd make a couple of guesses:

1. maybe imagemagick uses a different, more performant, filter when resizing the image
2. I found imagemagick to be very sensitive to memory consumption: bigger files means more memory used and maybe you encountered a memory leak or some other problem.

I'd also like to suggest a couple of tricks I use to speedup image resizing:

1. provide and use the thumbnail function, which is useful when creating (as it says) thumbnails (I think this is a common use case for imagemagick on the web)
2. use the -size switch to limit memory size of the image (http://www.imagemagick.org/script/command-line-options.php#size) I've seen this to reduce memory consumption in many cases
3. using libjpeg-turbo give a good boost when resizing jpegs

[laszbalo]

Thanks for your suggestions, I will investigate them further.

With this issue I simply wanted to point out, that by using medium/high resolution images in test/benchmark.js, the results are not that compelling, that the readme states.

e.g.

Performance - simple thumbnail creation

imagemagick: 16.09ms per iteration
imagemagick-native: 0.89ms per iteration

The above statement only true, if we use a small file. In the benchmark.js a 58x66 pixel image was converted to a 48x48 pixel image.
For bigger images using imagemagick instead of imagemagick-native gives a much better result.

OFF: For the sake of completeness I was benchmarking the gm module as well, which performed very similar to imagemagick. They both outperformed imagemagick-native.

[paolochiodi]

@laszbalo Let me know what you discover.
I'm not a contributor to this project and maybe not the right place to say this, but I'd suggest to investigate graphicsmagick if you don't need some fancy new option of imagemagick. In my experience it can be faster (also, being a fork of image magick it has almost same command line api and thus is easy to switch)

Meanwhile let's see if @mash have a better explanation

[mash]

On my environment, same tests produce:

# System Version: OS X 10.10 (14A343f)

% node -v
v0.10.28

% convert -version
Version: ImageMagick 6.8.9-1 Q16 x86_64 2014-06-20 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC Modules
Delegates: bzlib freetype jng jpeg ltdl lzma png xml zlib

# benchmark.js modified to accept process.argv, and commented memory consumption out

% node test/benchmark.js test/test.jpg
resize: 8.71ms per iteration
resize_native: 0.83ms per iteration

% node test/benchmark.js test/platform_9_and_three_quarters-wallpaper-800x600.jpg
resize: 25.15ms per iteration
resize_native: 15.77ms per iteration

% node test/benchmark.js test/platform_9_and_three_quarters-wallpaper-960x540.jpg
resize: 26.59ms per iteration
resize_native: 18.09ms per iteration

% node test/benchmark.js test/platform_9_and_three_quarters-wallpaper-2800x2100.jpg
resize: 181.18ms per iteration
resize_native: 198.53ms per iteration

% node test/benchmark.js test/platform_9_and_three_quarters-wallpaper-2880x1620.jpg
resize: 152.19ms per iteration
resize_native: 163.02ms per iteration

So a little bit different results, but I see the same trend; -native takes more time on larger images.

Well, the trend is not surprising,
the point of using this module is to reduce CPU time of forking a new convert(1) process, while CPU time for fork is much less important when converting large images (the actual converting takes the most CPU time).
But ideally if this imagemagick-native does the same thing with convert(1), it should be a little faster than imagemagick module on larger images too.
So there should be some difference in implementation details, which I don't know about yet.

[mash]

Discovered node-imagemagick 's default options: filter and sharpening is the hidden optimization,
and applying those to node-imagemagick-native (or disabling those in node-imagemagick) made node-imagemagick-native faster than node-imagemagick on larger images too.

[mash]

With version 1.3.0 released just now using optional parameters to resize,

% node test/benchmark.js test/test.jpg
resize: 8.83ms per iteration
resize_native: 0.79ms per iteration

% node test/benchmark.js test/platform_9_and_three_quarters-wallpaper-800x600.jpg
resize: 24.15ms per iteration
resize_native: 12.27ms per iteration

% node test/benchmark.js test/platform_9_and_three_quarters-wallpaper-960x540.jpg
resize: 25.4ms per iteration
resize_native: 13.26ms per iteration

% node test/benchmark.js test/platform_9_and_three_quarters-wallpaper-2800x2100.jpg
resize: 189.58ms per iteration
resize_native: 158.87ms per iteration

% node test/benchmark.js test/platform_9_and_three_quarters-wallpaper-2880x1620.jpg
resize: 157.81ms per iteration
resize_native: 125.71ms per iteration

node-imagemagick-native is faster for all sizes on my environment,
but I see otherwise on some other environments.

[hbakhtiyor]

from this performance test, imagemagick is a bit fast than imagemagick-native

what do you think?