Profiling + Indy
William Louth (JINSPIRED.COM)
william.louth at jinspired.com
Fri Oct 14 00:54:28 PDT 2011
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 at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
More information about the mlvm-dev
mailing list