Re: [csjava-developer] performance puzzle

[Thomas J. <ntm...@gm...>]

On 7/22/05, Toby Donaldson <tj...@sf...> wrote:
> Thanks to Thomas and Daryl for trying this ... I realized that the poor
> performance only seems to occur with one particular image: lake1.jpg
I've tested it out. The image is definitely problematic. Out of
curiousity, I tried saving it as a raw bitmap, and the conversion just
flew by. I also tried jpegs of identical dimensions, which all
converted quickly (will try to generate some test patterns later).
Re-encoding the image as jpeg (several different permutations of
Gimp's Jpeg exporter settings) only served to give a fast conversion.
By the looks of things, I think it's a problem with the file encoding.
If not, then you've found a unique worst-case scenario for Sun's JPEG
decoder.

Here's some interesting excerpts from the profiler (collected with
java -Xprof myTest lake1.jpg | tee profile.log)

  Interpreted + native   Method                       =20
  0.4%     0  +    22    sun.awt.color.CMM.cmmColorConvert
  0.3%     0  +    15    sun.awt.color.CMM.cmmGetTransform
  0.3%     0  +    13    sun.awt.color.CMM.cmmCombineTransforms
  0.2%     0  +     9    com.sun.imageio.plugins.jpeg.JPEGImageReader.readI=
mage
  0.1%     5  +     0    myTest.test4
  0.1%     0  +     3    java.util.zip.ZipFile.open
  0.1%     3  +     0    sun.awt.color.ICC_Transform.colorConvert
  0.0%     0  +     2    sun.awt.color.CMM.cmmGetNumComponents
  0.0%     0  +     2    sun.awt.color.CMM.cmmGetTagSize
[snip]

     Compiled + native   Method                       =20
  1.1%    56  +     0    sun.awt.color.CMMImageLayout.<init>
  0.8%    44  +     0    java.awt.color.ICC_ColorSpace.fromRGB
  0.4%    20  +     0    java.awt.color.ICC_ColorSpace.toRGB
  0.2%    12  +     0  =20
java.awt.image.ComponentColorModel.getNormalizedComponents
  0.2%     6  +     2    sun.awt.color.ICC_Transform.colorConvert
  0.2%     8  +     0    java.awt.image.ComponentColorModel.getDataElements
  0.1%     7  +     0    java.awt.image.ComponentColorModel.getRGB
[snip]

         Stub + native   Method        =20
 64.4%     0  +  3340    sun.awt.color.CMM.cmmColorConvert
 29.4%     0  +  1523    sun.awt.color.CMM.cmmGetNumComponents
  0.1%     0  +     7    java.lang.StrictMath.pow
  0.0%     0  +     1    java.lang.Object.clone

Flat profile of 61.52 secs (5160 total ticks): Java2D Disposer

Removing the call to write the aRGB values back in to the image neatly
cuts the runtime in half, as well as the number of color conversions.
         Stub + native   Method                       =20
 61.5%     0  +  1647    sun.awt.color.CMM.cmmColorConvert
 29.0%     0  +   776    sun.awt.color.CMM.cmmGetNumComponents
[snip]
Flat profile of 32.26 secs (2627 total ticks): Java2D Disposer

I'm not entirely sure how representative these figures are of the
normal behaviour when operating on plain aRGB data, as trials run too
fast for the profiler's 10Hz sampling rate. I'll look in to gathering
some more useful statistics tomorrow.


As a side-note, I just did a check-out of csjava and spent a solid
hour trying to fix the project's classpath to no avail. By the looks
of things, we are tied to Eclipse 3.0.1 for Windows (the swt includes
). What are everyone's thoughts on adding the libs to the CVS
repository so that we can use a relative classpath?