Repository navigation
add jimp test to benchmarks? #275
Description
JIMP looks like it might be an interesting addition to the benchmarks:
https://github.com/oliver-moran/jimp
It's a pure JS image resize library. I doubt if it's especially quick or low on memory use, but it is very easy to maintain and has picked up some users recently.
Activity
lovell commentedon Sep 26, 2015
Thanks for the tip-off John, will do.
https://twitter.com/Rich_Harris/status/647369066399842304
lovell commentedon Sep 27, 2015
Early testing suggests jimp is currently about half the speed of (CImg-based) lwip for a typical JPEG>resize>JPEG roundtrip.
The bilinear resizing logic is from https://github.com/taisel/JS-Image-Resizer
JPEG decompression from https://github.com/notmasteryet/jpgjs
JPEG compression from https://github.com/owencm/javascript-jpeg-encoder
lovell commentedon Sep 27, 2015
Correction: jimp and lwip appear to perform at around the same order of magnitude.
Some results from a ~5 year old quad-core AMD box using Node v0.12 (lwip doesn't support Node v4 yet):
jimp-buffer-buffer x 0.76 ops/sec ±3.60% (8 runs sampled)
jimp-file-file x 0.70 ops/sec ±8.03% (8 runs sampled)
lwip-file-file x 0.73 ops/sec ±8.75% (8 runs sampled)
lwip-buffer-buffer x 0.73 ops/sec ±4.26% (8 runs sampled)
imagemagick-file-file x 4.86 ops/sec ±2.44% (28 runs sampled)
imagemagick-native-buffer-buffer x 2.80 ops/sec ±4.16% (18 runs sampled)
gm-buffer-file x 3.51 ops/sec ±1.46% (22 runs sampled)
gm-buffer-buffer x 3.49 ops/sec ±2.20% (22 runs sampled)
gm-file-file x 3.56 ops/sec ±1.23% (22 runs sampled)
gm-file-buffer x 3.41 ops/sec ±3.50% (21 runs sampled)
sharp-buffer-file x 17.91 ops/sec ±0.25% (86 runs sampled)
sharp-buffer-buffer x 17.99 ops/sec ±0.15% (87 runs sampled)
sharp-file-file x 17.44 ops/sec ±0.17% (84 runs sampled)
sharp-file-buffer x 17.51 ops/sec ±0.20% (84 runs sampled)
I'll try to run these tests on a more representative AWS instance later today.
jcupitt commentedon Sep 27, 2015
Interesting! JS really is impressively quick.
The decoder doesn't seem to do shrink on load, as far as I can see, that would get them another x 8 speed up. And of course bilinear is probably not good enough for many applications.
Add jimp to perf tests #275
lovell commentedon Sep 28, 2015
When the proposed SIMD data type lands in the V8 JavaScript engine we might have found a liborc replacement :)
jcupitt commentedon Sep 28, 2015
Huh, nice, I hadn't come across SIMD.js. Yes, for things like JPEG decode it should be worth a x3 or x4 speedup.
lovell commentedon Oct 10, 2015
The clock speed on the c4.xlarge EC2 instances seems to vary between 2.6 and 3.3 GHz. I believe this is due to Intel's "Turbo Boost" feature that will auto-overclock based on (lack of) CPU temperature. The
cat /proc/cpuinfocommand reported a clock speed of 2.9GHz whilst these tests ran.