Rumor has it that graphicsmagick is faster than IM. Let's test the same thumbnailing commands we use in production for JPGs and PNGs and find out if that's true.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T44725 Multimedia file format support (tracking) | |||
| Open | Feature | None | T21073 Add support for using graphicsmagick instead of imagemagick for thumbnailing | ||
| Resolved | • Gilles | T107885 Investigate graphicsmagick performance |
Event Timeline
Comment Actions
Tests conducted using the GM that debian gives me on the VM, which is actually a year older than the IM version we use.
On thumbnailing a large PNG (17MP), GM is 2.7 times faster than IM:
vagrant@mediawiki-vagrant:/vagrant$ perf stat -r 100 -d convert -quality 95 -background white test.png -thumbnail 600x600! -set comment "Fi source: http://127.0.0.1:8080/wiki/File:STD_Depth_Coded_Stack_Phallodin_Stained_Actin_Filaments.png" -depth 8 -rotate -0 test-thumb.png
Performance counter stats for 'convert -quality 95 -background white test.png -thumbnail 600x600! -set comment Fi source: http://127.0.0.1:8080/wiki/File:STD_Depth_Coded_Stack_Phallodin_Stained_Actin_Filaments.png -depth 8 -rotate -0 test-thumb.png' (100 runs):
4103.550328 task-clock (msec) # 1.505 CPUs utilized ( +- 1.14% )
166 context-switches # 0.040 K/sec ( +- 8.63% )
13 cpu-migrations # 0.003 K/sec ( +- 4.59% )
4,212 page-faults # 0.001 M/sec ( +- 1.50% )
<not supported> cycles
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
<not supported> instructions
<not supported> branches
<not supported> branch-misses
<not supported> L1-dcache-loads
<not supported> L1-dcache-load-misses
<not supported> LLC-loads
<not supported> LLC-load-misses
2.725939048 seconds time elapsed ( +- 1.06% )
vagrant@mediawiki-vagrant:/vagrant$ perf stat -r 100 -d gm convert -quality 95 -background white test.png -thumbnail 600x600! -set comment "Fi source: http://127.0.0.1:8080/wiki/File:STD_Depth_Coded_Stack_Phallodin_Stained_Actin_Filaments.png" -depth 8 -rotate -0 test-thumb.png
Performance counter stats for 'gm convert -quality 95 -background white test.png -thumbnail 600x600! -set comment Fi source: http://127.0.0.1:8080/wiki/File:STD_Depth_Coded_Stack_Phallodin_Stained_Actin_Filaments.png -depth 8 -rotate -0 test-thumb.png' (100 runs):
1517.987884 task-clock (msec) # 1.098 CPUs utilized ( +- 0.97% )
109 context-switches # 0.072 K/sec ( +- 2.14% )
12 cpu-migrations # 0.008 K/sec ( +- 2.90% )
2,879 page-faults # 0.002 M/sec ( +- 1.27% )
<not supported> cycles
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
<not supported> instructions
<not supported> branches
<not supported> branch-misses
<not supported> L1-dcache-loads
<not supported> L1-dcache-load-misses
<not supported> LLC-loads
<not supported> LLC-load-misses
1.382675105 seconds time elapsed ( +- 1.00% )And on thumbnailing a large JPG (29MP), GM is 30% slower than IM:
vagrant@mediawiki-vagrant:/vagrant$ perf stat -r 100 -d convert -quality 80 -background white -define jpeg:size=800x257 test.jpg -thumbnail 800x257! -set comment "File source: http://127.0.0.1:8080/wiki/File:View_from_a_ridge_between_Segla_and_Hesten,_Senja,_Norway,_2014_August.jpg" -depth 8 -sharpen 0x0.4 -rotate 0 test-thumb.jpg
Performance counter stats for 'convert -quality 80 -background white -define jpeg:size=800x257 test.jpg -thumbnail 800x257! -set comment File source: http://127.0.0.1:8080/wiki/File:View_from_a_ridge_between_Segla_and_Hesten,_Senja,_Norway,_2014_August.jpg -depth 8 -sharpen 0x0.4 -rotate 0 test-thumb.jpg' (100 runs):
753.920985 task-clock (msec) # 1.253 CPUs utilized ( +- 0.81% )
59 context-switches # 0.078 K/sec ( +- 1.17% )
9 cpu-migrations # 0.012 K/sec ( +- 3.01% )
4,198 page-faults # 0.006 M/sec ( +- 1.34% )
<not supported> cycles
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
<not supported> instructions
<not supported> branches
<not supported> branch-misses
<not supported> L1-dcache-loads
<not supported> L1-dcache-load-misses
<not supported> LLC-loads
<not supported> LLC-load-misses
0.601895621 seconds time elapsed ( +- 0.96% )
vagrant@mediawiki-vagrant:/vagrant$ perf stat -r 100 -d gm convert -quality 80 -background white -define jpeg:size=800x257 test.jpg -thumbnail 800x257! -set comment "File source: http://127.0.0.1:8080/wiki/File:View_from_a_ridge_between_Segla_and_Hesten,_Senja,_Norway,_2014_August.jpg" -depth 8 -sharpen 0x0.4 -rotate 0 test-thumb-gm.jpg
Performance counter stats for 'gm convert -quality 80 -background white -define jpeg:size=800x257 test.jpg -thumbnail 800x257! -set comment File source: http://127.0.0.1:8080/wiki/File:View_from_a_ridge_between_Segla_and_Hesten,_Senja,_Norway,_2014_August.jpg -depth 8 -sharpen 0x0.4 -rotate 0 test-thumb-gm.jpg' (100 runs):
1046.111455 task-clock (msec) # 1.127 CPUs utilized ( +- 0.64% )
63 context-switches # 0.060 K/sec ( +- 1.04% )
12 cpu-migrations # 0.012 K/sec ( +- 2.57% )
2,957 page-faults # 0.003 M/sec ( +- 0.94% )
<not supported> cycles
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
<not supported> instructions
<not supported> branches
<not supported> branch-misses
<not supported> L1-dcache-loads
<not supported> L1-dcache-load-misses
<not supported> LLC-loads
<not supported> LLC-load-misses
0.928362767 seconds time elapsed ( +- 0.67% )Comment Actions
GraphicsMagick doesn't seem to be a silver bullet that will make all of our thumbnailing faster, but it could be very useful for PNGs.
Comment Actions
It would be useful to test their performance programmatically over a larger sample (say, 1000 random PNGs and 1000 random JPGs), I think. In particular, I'd worry - for example - that GM is better for large PNGs but *worse* for smaller PNGs. I think for Wikimedia wikis we'd also be interested in RAM usage, wouldn't we?
Comment Actions
There's a lot of criteria to judge an image renderer on. We should be careful that the faster speed doesn't result in reduced quality, significantly bigger file sizes, etc.
Comment Actions
I've been comparing speed at equal size and quality. Quality was verified with DSSIM. And so far for all alternatives I've investigated, the size was extremely close between the different tools for a given DSSIM quality level. Note that size/quality concerns are generally more of an issue for lossy formats.