Tom Lane píše v pá 11. 12. 2009 v 13:56 -0500:
> Robert Haas <robertmhaas@gmail.com> writes:
> > As far as I am concerned that is way too much, particularly
> > considering that your test case isn't designed to be particularly
> > memory-allocation intensive, and if it is up to me I will reject this.
> > Even a quarter-percent slowdown for a feature that will be used only
> > by a small fraction of users only a small fraction of time time seems
> > totally unacceptable to me.
>
> It seems to me that anyone who really needs this can instrument the
> alloc functions anyway --- isn't one of the features of DTrace supposed
> to be that you can monitor calls to a particular function without any
> prearranged code support? Or is that one of the things like "zero
> overhead" that turns out to be more marketing-speak than reality?
There are several types of probes. For example for PID provider probes
you can monitor all entry and return point from global function. And
also you can put probe on each asm instruction in the function. These
probes have zero overhead, because dtrace understand ABI and know where
args are. Unfortunately user defined probes has small overhead which is
price for universal solution which works with all compilers and linkers.
> Anyway I concur with Robert's opinion that the use-case is far too small
> to justify incurring a measurable overhead for everybody.
OK.
> There might
> be some small argument for putting these in under an extra #ifdef, but
> they wouldn't get into any regular production build.
unfortunately #ifdef solution kills main dtrace goal - without
recompilation :(.
Zdenek