DTrace variable types

When using DTrace it is important to understand variable types and when each should be used. Using the wrong type can increase the overhead of your DTrace script, leading to degraded performance and DTrace error messages (“dynamic variable drops”).

When discussing this with someone recently, we hit upon a neat way to explain it: listing variable types in order of preference. Work through the list below and pick the first variable type that can do the job.

DTrace variable types, in order of preference:

type prefix scope overhead multi-CPU safe example assignment
aggregation @ global low yes @x = count();
clause local this-> clause instance[1] very low yes this->x = 1;
thread local self-> thread medium yes self->x = 1;
scalar none global low-medium no[2] x = 1;
associative array none global medium-high no[2] x[y] = 1;



Print Friendly
Posted on November 25, 2011 at 4:39 pm by Brendan Gregg · Permalink
In: DTrace · Tagged with: 

6 Responses

Subscribe to comments via RSS

  1. Written by Frank Ch. Eigler
    on November 27, 2011 at 1:06 pm

    Brendan, can you elaborate the global variable overhead / safety issue? It’d surprise me if dtrace lacked proper concurrency controls over such things, but if it does lack them, where would the “medium-high” overhead come from?

    • Written by Brendan Gregg
      on November 29, 2011 at 3:22 pm

      G’Day Frank,

      Yes, global scalars and global associative arrays do not lock. The higher overhead is due to them being dynamic variables and not being cacheable in predicates. There may also be more overhead due to multi-CPU cache coherency effects, that aren’t seen with thread-local variables (which I’ve suspected; I’d need to perform analysis to confirm if needed).

  2. Written by Brendan Gregg
    on November 29, 2011 at 3:26 pm

    UPDATE: I split globals into scalars and associative arrays, since they are handled differently (thanks Bryan!).

  3. Written by Brian Utterback
    on November 30, 2011 at 10:05 am

    You show scalar as “low-medium” overhead and thread local as just “medium” overhead. Doesn’t that imply that a scalar is more efficient than a thread local variable? But below the table you say to use self variable whenever possible instead of scalars. Huh?

    • Written by Brendan Gregg
      on November 30, 2011 at 11:49 am

      Sorry, when I updated the table I didn’t update the example below it, I’ve fixed that now. Thanks for pointing it out.

      To elaborate a bit more: scalars may be corrupted due to the lack of locking and they aren’t very useful, so I think it would be both dangerous and confusing to encourage their use before thread locals. I believe they are faster due to fewer lookups in the implementation, but it’s not something I’ve tested to confirm since their use is so rare. I sometimes use them for BEGIN { scriptstart = timestamp; }, but not a lot more.

  4. Written by Getting Started with Dtrace « Ukrainian Oracle User Group
    on December 21, 2011 at 8:18 pm

    [...] Dtrace variables (from Brendan’s blog see: http://dtrace.org/blogs/brendan/2011/11/25/dtrace-variable-types/ ) [...]

Subscribe to comments via RSS