DTrace: Probe Performance Hit
DTrace: Probe Performance Hit
- Subject: DTrace: Probe Performance Hit
- From: Eric Gorr <email@hidden>
- Date: Fri, 7 May 2010 11:57:36 -0400
I am looking into the performance hit of doing probe enabled checks.
To test this, I created the default Cocoa application and then wrote:
- (unsigned long) myMethod:(unsigned long)inX
{
return inX + 1;
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
if ( DTRACETEST_TEST_START_ENABLED() )
DTRACETEST_TEST_START();
unsigned long x;
unsigned long y = 0;
for ( x = 0; x < 1000000000; x++ )
{
y = [self myMethod:x];
if ( DTRACETEST_TEST_MINE_ENABLED() )
{
DTRACETEST_TEST_MINE();
}
}
if ( DTRACETEST_TEST_END_ENABLED() )
DTRACETEST_TEST_END();
printf( "%lu", y );
// Insert code here to initialize your application
}
In the Debug build,
If I remove DTRACETEST_TEST_MINE_ENABLED block, the time between the start and end probes is ~8.8 seconds.
Adding DTRACETEST_TEST_MINE_ENABLED back in, but keeping the probe disabled (i.e. DTRACETEST_TEST_MINE_ENABLED returns false), took ~8.9 seconds.
In the Release build,
If I remove DTRACETEST_TEST_MINE_ENABLED block, the time between the start and end probes is ~5.7 seconds.
Adding DTRACETEST_TEST_MINE_ENABLED back in, but keeping the probe disabled, took ~6.4 seconds.
The overhead has increased significantly in the release build.
This doesn't seem like it is as close to zero cost as I initially thought it was, leading me to think that i may not be measuring what I think I am measuring.
Based on these results, it would seem that one would want to keep probes out of the tightest loops in an application.
But, considering how pervasive such things are even in Mac OS X, my conclusion does not seem to be correct.
So, where did I go wrong? (or am I right?) _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden