DTrace probes are horrendously slow. It even states it in the docs. Please @see http://opencore.jinspired.com/?p=5459 - If you’re not metering you’re not trying hard enough to be the best – Part 2 of 3
Anyway you first need to know what you want to measure and to do this iteratively would be excruciating with DTrace. Once you get down to very low latency high frequency profiling you need to do this across multiple runs training the measurement (in our case metering) engine. Online & Offline Intelligence in Java Application Performance Measurement http://opencore.jinspired.com/?p=6217 If Charles post a few benchmarks (links, docs) I will write up a post showing this in practice with such ones. I can do this from both a Java or Ruby perspective because we can translate JRuby exec ctx into Ruby. On 14/10/2011 09:47, rvjansen wrote: > Charlie, > > there are the DTRACE probes in Java on MacOSX (and Solaris) - you might > want to look into those. > > best regards, > > René Jansen. > > On Fri, 14 Oct 2011 03:52:23 +0000, Charles Oliver Nutter wrote: >> I'm looking to get back into JRuby + Indy work now that the heaviest >> conferences are behind me. Part of this involves running larger >> benchmarks where the hot spots may not be apparent at a glance. In >> order to investigate performance on such benchmarks, I will want to >> do >> some profiling. But what should I use? >> >> For really egregious problems, the sampling profiler (-Xprof) "sort >> of" works. It's grossly inaccurate when there's no stand-out hotspot, >> but if something is incredibly bad it usually shows it. So that's >> option 1. >> >> There's -Xrunhprof:cpu=times, which is more accurate, but the impact >> to running code is enormous, there's no way to filter out >> uninteresting code (like JDK core), and I have no idea if it works >> properly with indy (given that there's ongoing work to make JVMTI + >> indy play nice). That's option 2. >> >> Are either of these options any good? What else do you recommend? >> >> - Charlie >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
