| |||
| |||
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
I second Greg's and Dave's suggestion, adding some more points. Greg was right in asking more details about what do you intend to do with the images. I have some similar problem to yours, with the difference that I'm dealing with JPEGs. By running some profiling (which in short is Dave's suggestion), I found that my first bottleneck was the processing subsequent to reading (in a few words, I'm reading JPEG previews, that can be rescaled on the fly while rendering. Rescale performance changes dramatically in function of the SampleModel (e.g. by creating an image 'compatible' with the rendering subsystem and then copying the raster to it you have huge gains, also because it can take advantage of the graphic card hardware). Of course, changing the SampleModel has a cost, that can be avoided if I store my previews with the right format. Of course this has a fallback, since the optimization holds only for one platform (e.g. Mac OS X rather than Windows). These are trade-offs that must be placed in context. Now, I have really a performance bottleneck while reading original images the first time, in order to compute the preview. I'm following Greg's approach, that is comparing the performance with a native library and then profiling what other could happen. So far I've discovered, also thanks to some support from this list, that there is actually a problem in the native JPEG reader of the Java Runtime, since it appears that has been compiled without optimizations. But I've also found huge differences with Linux, testing different images, so probably there is something related to the specific sub-format used. All things that are hard to discover if you don't follow Greg's advice.
On Sep 19, 2008, at 12:35 AM, Bill Janssen wrote:
Greg Guerin <email@hidden> wrote:
I don't have a specific answer, just a strategy for finding answers.
Sorry, not interested. I'm interested in knowing if anyone out there knows the specific answer, and is willing to share it.
If the PNG-reading time were reduced to exactly 0 ms (i.e. infinitely fast), would the overall task then be fast enough for you to call it successful?
That would be superb. How do I do it?
I'm reasonably certain that was part of Greg's strategy for finding answers. That is, suppose that the PNG-reading time was taken out of the equation, in that it was so fast that it was essentially instantaneous. At that point, would your app be fast enough? This is related to Amdahl's law (http://en.wikipedia.org/wiki/Amdahl%27s_law) and the concept of diminishing returns. Which I'm sure you already know.
Example for those who slept through that lecture:
Suppose for each image, it takes 200ms to read as PNG, 40ms to frobnicate, 120ms to bazzle it, 98ms to apply the quuux^2 transform, and 150ms to write out a transformed image. Your current time would be 608 ms/sec.
If you manage to increase your reading speed so it now takes only 100ms, your overall process per image is 508ms. Thus you've halved your reading time, but the overall process only sped up by 16%. Any further improvements to reading speed will make less difference to the overall process.
Bill
Dave Watson
-- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog email@hidden - mobile: +39 348.150.6941
_______________________________________________ Do not post admin requests to the list. They will be ignored. Java-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/email@hidden
| References: | |
| >Re: how to read images fast with Apple Java? (From: Greg Guerin <email@hidden>) | |
| >Re: how to read images fast with Apple Java? (From: Bill Janssen <email@hidden>) | |
| >Re: how to read images fast with Apple Java? (From: David Watson <email@hidden>) |
| Home | Archives | FAQ | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved.
