400 Horsepower: Image I/O Improvements in Mustang
Happy New Year!
It's been a while since my last post, but I wanted to kick off 2006 by reporting some nice performance improvements in Image I/O. As you may know, we're constantly finding ways to boost performance in various parts of the JDK. In JDK 5 we did some performance work in Image I/O, specifically to avoid finalization in the JPEGImageReader, which made for huge gains in scalability and performance of reading JPEG images. We heard some great feedback about those changes, but we knew there was more work to be done.
So a couple months ago, I spent a few solid weeks digging deep into the Image I/O framework and the core plugins trying to find ways to improve performance. I've identified a few long term things we can do to optimize certain plugins even more, perhaps in the Dolphin timeframe. But along the way, I uncovered (and picked off) some low hanging fruit and fixed them in Mustang b63. I won't bore you with all the details, but if you're interested, you can read the evaluations of the following bug reports, all of which were fixed in b63:
- 6347575: FileImageInputStream.readInt() and similar methods are inefficient
- 6348744: PNGImageReader should skip metadata if
- 6354056: JPEGImageReader could be optimized
- 6299405: ImageInputStreamImpl still uses a finalize() which causes java.lang.OutOfMemoryError
- 6354112: increase compiler optimization level for libjpeg to improve runtime performance
Also in those evaluations you'll find lots of raw J2DBench numbers and analysis, but ASCII can be so boring. What blog entry would be complete without a Ross Perot-style chart? [Did I really just make a Ross Perot reference? How pathetic... Maybe next time I'll make a clever remark about Dan Quayle's potatoe?] Feast yr eyes:
That 20x20 JPEG score for JDK 1.4.2 isn't a glitch; it really was that bad (yet another demonstration of the evils of finalizers and explicit System.gc() calls)... Note that this chart only shows results for small images just because I'm tired and lazy, but similar improvements can be seen for larger images as well. For example, I've measured a 53% improvement in reading 4000x4000 pixel JPEG images between Mustang b62 and b63.
And yet somehow I'm still not satisfied... We'll continue to work on this stuff as time goes on. In the meantime, please download the latest Mustang snapshot and let us know if these Image I/O enhancements are helping your application.
Are You Ready To Testify? I Give You... A Testimonial!
While we're on the subject, just yesterday I received some exciting feedback from Jeffrey Moore and James Todd from the JXTA project. You may have read recently that MyJXTA now has a video conferencing feature, which uses MJPEG as the video protocol. It's not the most efficient video format out there, but it was easy for them to use the JPEGImageReader in Image I/O to assist in decoding the JPEG frames. They were asking about JPEG decoding performance and I suggested that they try the latest Mustang builds because of the fixes I mentioned above. It turns out that with the latest Mustang snapshots they are seeing CPU usage cut in half when decoding an MJPEG stream at 30 fps (compared to JDK 5)! The fixes above had a lot to do with it, but I know there have been other performance improvements across the stack (in HotSpot and elsewhere) that are probably contributing as well. This chart tells all:
Meet the Java Client Team
When he's not working on one of his cool JOGL/Java2D demos, you can find Romain snapping some photos of the desktop Java geeks that work here on Sun's Santa Clara campus. If you've ever wondered about the faces behind the names, now's your chance to satisfy your curiosity. Or maybe you have a favorite Java2D or Swing bug that still isn't fixed? Here's what you do: print out the responsible engineer's photo, tape it to your office dartboard, and then play a little game of cricket... It may not get that bug fixed any sooner, but what better way is there to relieve the frustration of waiting?
Get Involved with Mustang!
Well, perhaps that was a tad sinister. I would never condone violence against my fellow Sun engineers (except maybe Chet, but I kid, I kid). If you really do want to see a languishing JDK bug fixed, let me once again recommend the JDK Collaboration project (aka Project Peabody). We've had lots of external developers digging into the JDK source code and submitting complete bug fixes, but we'd love to see more, so why not get involved? There are plenty of open bugs on the "starter list" that you can hack on to get your feet wet.
On that note, I recently had the pleasure of working with one such external developer, R