Joe,
> I'm having some performance "issues" with the jpeg codec (I suspect it applies to
>other codecs as well). I realize that the jpeg codec is part of the j2se, and only
>facaded by jai, but the j2D mailing list is lifeless and this is the only forum I can
>find where people are discussing these issues. Besides, the codecs are an important
>part of jai, so this topic is highly relevant to this forum.
I'm copying the java2d-interest list on this reply nonetheless.
> I'm running J2SE 1.4 on windows. I've been memory and cpu profiling a simple program
>that exercises the jpeg decoder a bit. Here's the program:
>
> for(int i=0;i<someJpegFiles.length; i++)
> {
> ImageDecoder aDecoder = ImageCodec.createImageDecoder( "jpeg", someJpegFiles[i],
>null);
>
> Raster aRaster = aDecoder.decodeAsRaster();
>
> }
>
>
> Pretty innocent looking. The File[] points to 20 jpeg files, each of which is about
>800K on the filesystem and 3.5Mb uncompressed.
>
> I'm getting pretty crappy performance (dog slow). The profiler (OptimizeIt) shows
>why the performance is so bad. The process is largely gc-bound-- most of the cpu
>cycles are being consumed by the garbage collector. A look at the allocation tracker
>shows that a *huge* number (thousands) of objects are being created to decode these
>20 files. What's worse, they take up a fair amount of space. To decode roughly 70Mb
>worth of image files the decoder allocates about 80Mb worth of byte[] and 102Mb worth
>of int[]. The time consumption traces show that, on top of all the time spent by the
>garbage collector, a large amount of time is spent in object allocation.
What kind of dog? ;-)
I can only speak for the JAI wrapper and not for the bundled JPEG
codec. There are a couple of things you can do:
. use decodeAsRenderedImage() instead of decodeAsRaster() which causes
additional object creation if not memory allocation and copying.
. pass in a JPEGDecodeParam on which you have invoked
setDecodeToCSM() with a parameter of 'false'. For more information
please refer to
http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/com/sun/media/jai/codec/JPEGDecodeParam.html
> Have I missed something? It seems like the performance of the jpg codec, and
>consequently jai, could be dramatically improved by simply pooling and reusing
>objects (probably mostly in the databuffers). But I can't find any hooks where I can
>supply my recycled objects. How are people dealing with this issue? Are there some
>hidden hooks for buffer recycling? Are there some high performance codecs that I
>don't know about?
We are doing some work on the concept of buffer recycling and hope to
include this in the next release of JAI. This will not have any effect
on what happens within the bundled JPEG codec however.
> Thanks for any insights, opinions, acknowledgements, anything.
Have you performed your tests using only the bundled JPEG API
http://java.sun.com/j2se/1.3/docs/guide/2d/api-jpeg/
so as to isolate overhead which may be added by JAI itself?
Brian
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
