I should add that if you're running this against a u2ish build and seeing poor performance, we need to talk. I'm not seeing that locally, and you shouldn't see it either.
- Charlie On Wed, Nov 30, 2011 at 2:42 PM, Charles Oliver Nutter <head...@headius.com> wrote: > On Wed, Nov 30, 2011 at 2:03 PM, Stephen Bannasch > <stephen.banna...@deanbrook.org> wrote: >> Hi Charlie, >> >> Is your latest work going on in the indy_update branch? > > No, that's old stuff. I should wipe it out. I can explain your perf > issue below, though. > >> I have a simple Ruby xml processing benchmark that compares several Ruby XML >> libraries including rexml which is part of the >> Ruby standard library. >> >> My test measures the time to do the following 100 times: >> >> - open 98k XML document and count one type of leaf element (466 entries) >> >> On the latest master version of JRuby the performance of rexml degrades >> dramatically using Java 1.7 and even more using mlvm. > ... >> Using the indy_update branch of JRuby however I get MUCH better results on >> 1.7 > > I'll take a guess and say you're running this against OpenJDK 7 GA, > right? The GA release was feature-complete, but a number of indy > features were implemented in weakly-optimized or unoptimized ways. For > example, a *critically* important feature for JRuby's invokedynamic > support -- SwitchPoint -- is just a full-on volatile read every time > you traverse the guard. I could enumerate the other issues with the GA > release's optimzation, but if you poke around the bug listings for u2 > you'll see the important JSR-292 improvements...most of which were > initiated by my performance testing in JRuby. > > If you use one of the Java 7u2 early access releases (and there's > builds of them called "OpenJDK 8" for OS X now) you should see > substantially better performance across the board. > > - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev