Performance regression in 6.5.9?

[DanKegel]

I ran into this when upgrading from Ubuntu 10.04 to Ubuntu 12.04.

Here's how I measured:

Code: Select all

wget http://kegel.com/imagemagick/slow/slow.jpg
time convert slow.jpg -depth 8 -auto-orient -strip -type TrueColorMatte -write PNG32:/tmp/img-conf.png '(' +clone -strip -resize 480x480 -write PNG32:/tmp/img-thumb.png +delete ')' -background 'rgba(255,255,255,.06)' -gravity center -resize 1920x1080 -extent 1920x1080 -write /tmp/img-slide.png -resize 480x270 -write /tmp/img-thumb-480x270.png -resize 160x90 /tmp/img-thumb-160x90.png 
 
bench-6.5.7-9.log:14.18user 0.20system 0:08.99elapsed 159%CPU (0avgtext+0avgdata 429056maxresident)k
bench-6.5.8-10.log:14.28user 0.22system 0:09.64elapsed 150%CPU (0avgtext+0avgdata 429648maxresident)k
bench-6.5.9-10.log:38.02user 0.12system 0:31.96elapsed 119%CPU (0avgtext+0avgdata 440832maxresident)k
bench-6.6.0-10.log:37.63user 0.21system 0:32.01elapsed 118%CPU (0avgtext+0avgdata 439408maxresident)k
bench-6.6.3-10.log:37.42user 0.25system 0:32.01elapsed 117%CPU (0avgtext+0avgdata 440816maxresident)k
bench-6.6.9-10.log:37.63user 0.23system 0:32.06elapsed 118%CPU (0avgtext+0avgdata 528848maxresident)k

And just now I verified it's still at r10000 of trunk (the tip of trunk crashes for me).

I had thought that --enable-modules made the problem go away, but I'm just having trouble
getting meaningful results when bisecting.

[DanKegel]

Figured out how to bisect properly. I uploaded my script and logs to
http://kegel.com/imagemagick/slow/bisect.tgz
I had to edit it each run to hard code the revision I wanted to test, but that wasn't too bad.

The culprit seems to be r971, and the likely hunk within that commit seems to be

Code: Select all

--- coders/jpeg.c       (revision 970)
+++ coders/jpeg.c       (revision 971)
@@ -731,17 +731,12 @@
          {
            if ((qvalue < hash[i]) && (sum < sums[i]))
              continue;
-           if ((qvalue <= hash[i]) && (sum <= sums[i]))
+           if (((qvalue <= hash[i]) && (sum <= sums[i])) || (i >= 50))
              image->quality=(unsigned long) i+1;
            if (image->debug != MagickFalse)
-             {
-               if (image->quality != UndefinedCompressionQuality)
-                 (void) LogMagickEvent(CoderEvent,GetMagickModule(),
-                   "Quality: %ld",image->quality);
-               else
-                 (void) LogMagickEvent(CoderEvent,GetMagickModule(),
-                   "Quality: %ld (approximate)",i+1);
-             }
+             (void) LogMagickEvent(CoderEvent,GetMagickModule(),
+               "Quality: %ld (%s)",i+1,(qvalue <= hash[i]) &&
+               (sum <= sums[i]) ? "exact" : "approximate");
            break;
          }
        }

[dlemstra]

Without that fix the quality of the image would be '0' instead of '96'. And it looks like the png coder will think that the quality is 75 instead of 96 and that will result in a different compression. I haven't tested this yet but that really looks like unwanted behavior.

Edit:
The png encoder really uses the quality of the jpeg to determine the compression. A patch for ImageMagick 6.8.6-9 Beta will available by sometime tomorrow. Thanks.