Menu
▾
▴
Re: [csjava-developer] performance puzzle
|
From: Daryl V. H. <dva...@sf...> - 2005-08-03 19:24:41
|
After performing several tests, I've come to the conclusion that there is something uncertain about lake1.jpg. It takes the longest of all the images I've tested with this program, and if I open it in a paint program (PaintShop Pro 5, in this case) and save it again without compression, it takes up more disk space, but takes only .22 seconds to convert to grayscale. So far, I have been unable to find any differences in header information, and don't know what in the world is going on as far as this image is concerned. I'm completely baffled by this. Daryl. Toby Donaldson wrote: > Thanks for looking into this, Daryl. Maybe the header of the file is > somehow corrupt, or uses some weird JPEG feature that the Java codec > doesn't handle. > > Toby > > On 25-Jul-05, at 10:22 PM, Daryl Van Humbeck wrote: > >> I've tested it too. >> >> I've found that this image, for some reason, takes much longer than >> most other images, even if they're larger. >> Strange. >> >> I'm going to check and see what Java says the format is as compared >> with other images. >> >> Daryl. >> >> Thomas Johnson wrote: >> >> >>> 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 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.readImage >>> 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 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 >>> 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 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 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? >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>> from IBM. Find simple to follow Roadmaps, straightforward articles, >>> informative Webcasts and more! Get everything you need to get up to >>> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opÌk >>> _______________________________________________ >>> csjava-developer mailing list >>> csj...@li... >>> https://lists.sourceforge.net/lists/listinfo/csjava-developer >>> >>> >>> >> >> >> -- >> Get Firefox! <http://www.spreadfirefox.com/? >> q=affiliates&id=106297&t=65> >> >> >> -- >> No virus found in this outgoing message. >> Checked by AVG Anti-Virus. >> Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/05 >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >> _______________________________________________ >> csjava-developer mailing list >> csj...@li... >> https://lists.sourceforge.net/lists/listinfo/csjava-developer >> >> > > -- > Dr. Toby Donaldson > School of Computing Science > Simon Fraser University (Surrey) > -- Get Firefox! <http://www.spreadfirefox.com/?q=affiliates&id=106297&t=65> -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.9/62 - Release Date: 02/08/05 |
