I hope I'm not stealing AndyA's thunder, but this just went by on p5p and I'm excited!
From: Andy Armstrong <andy@hexten.net>
I now have a dtraced bleadperl which runs no slower than the clean
version:
orig | dtrace | ratio
====================================
2.51239896 | 2.47904992 | 0.98672622
2.50696611 | 2.46995783 | 0.98523782
2.52996778 | 2.47554016 | 0.97848683
2.50457382 | 2.47788405 | 0.98934359
2.50622296 | 2.46893001 | 0.98511986
In fact in those tests the dtraced version is running marginally
faster. I'm putting that down to a happy code alignment or somesuch.
dtrace is Sun's new thing to allow you to do live tracing of function calls across the entire operating system without having to compile without any special flags and without a performance hit when you're not actively doing a trace. It's been ported to FreeBSD and OS X 10.5.
Unfortunately there's been trouble getting Perl to work with dtrace at the Perl function call level (rather than at the internal C opcode level) without a performance hit. Someone else can answer why, but it appears Andy has solved that problem! They're already discussing the possibility of, if dtrace is available, enabling it by default.
For those who can't wait for bleadperl Andy has Devel::DTrace available on CPAN, though it does have a performance hit.
Sun did the hard sums (Score:2)
To be fair Sun did all the heavy lifting. They added a quick "is this probe enabled" test that can be used to wrap the instrumentation code. In fact I'm told they developed it specifically to make dtrace fast enough for Perl! And it is fast. The benchmark figures there are for 10,000,000 calls to an empty subroutine - so if there was any performance hit to entry/exit it'd show.
Right now I'm working on getting Configure to handle dtrace. It's slightly complicated by the fact that Sun's /usr/sbin/dtrace and
Re: (Score:1)