Need for speed
Some more numbers for you as followup to my last measurements:
- jdk6: ~750ms
- my latest improved Escher/Java peers on Cacao: ~200ms
I wonder what Sun did to the shape renderer in jdk6. It’s quite slow compared to JDK5 and even much slower than the Escher peers. And that is without antialiasing just like the Java renderer. Probably this has to do with their work on the text renderer (which is even slower - ~1600ms - as it uses AA by default now).
It would be interesting to see how fast the Escher peers would run on hotspot. I’m thinking that a significant part of the performance gap between jdk5 and the escher peers is due to the performance of the VM itself as the escher peers and the shape renderer run comletely in java. Unfortunately it’s not trivial to port the peers to Sun’s JDK due to the few differences on the peer API. I’m still hoping that somebody will get hotspot running with GNU Classpath.
January 5th, 2007 at 4:41 am
Hello,
What kind of machine you’re running this on? 750ms seems to be way too high - I get around 80ms on my rather old SunBlade 2000 (that’s on solaris-sparc, so a little hard to compare, I guess - it also depends on the X server).
Anyway, we have improved the quality of our non-AA shape renderer in jdk6.
I don’t, however, see the performance drop you’re measuring - it’s actually
a little faster on jdk6.
Another thing: your test isn’t really correct. Since you’re rendering to the screen, all you do
is ask Java2D to issue rendering commands to the X server, which are then buffered by the
server until the queue is full.
If you want to measure the real rendering time, you’ll need to flush the queue by
calling Toolkit.sync() (which would cause XFlush() to be called, forcing the
X server to flush the request queue and complete the rendering).
Regarding the benchmarking - we have a good Java2D benchmark, which is unfortunately still
not open sourced (you can get a hold of it if you agree to the JRL license on jdk7.dev.java.net, it’s in j2se/src/share/demo/java2d/J2DBench) - it’s a very comprehensive set of Java2D benchmarks
(including different rendering destinations - BufferedImage, Screen, VolatileImage, etc).
You can also take a look at the way the rendering performance should be measured -
we basically measure how many iterations can be performed within a certain amount of time,
and then time that number of iterations (giving the hotspot some time to warm up first)
Thanks,
Dmitri
Java2D Team
January 5th, 2007 at 2:18 pm
Hi Dmitri,
In the meantime I also noticed that my benchmark is bad. In GNU Classpath we also have a set of Java2D benchmarks which shows better and more fair results:
http://kennke.org/blog/2007/01/03/a-better-comparison/
It seems that the result of my own little benchmark varies greatly from machine to machine. Which isn’t the case for the ‘real’ benchmarks.
January 5th, 2007 at 9:14 pm
> it seems that the result of my own little benchmark varies greatly from machine to machine.
Actually, that should be expected - different machines may be different hardware, drivers, etc.
What should be constant (or near constant) is the results from repeated runs on the same system.
We do our measurements on machines with minimal activity, no users logged in, networking disabled,
etc, and still get some variation =(
Also, if you just time a 1000 iterations of some operation and it only
takes say ~50ms - it’s too close to the error threshold (and timer resolution on some systems) -
so the results would vary greatly from run to run.
I really wish we had J2DBench open sourced - that way we can all use the same tool!
Oh well, it will be soon.
Thanks,
Dmitri