DTrace is many things to many people. To me it is a tool for engaging with complexity. Sure there’s an important place for the DTrace Toolkit, advanced OpenStorage analytics, Chime and other wonderful technologies built on DTrace (most of which don’t even come close to exposing the user to the more low-level cranium challenging detail), but for me DTrace remains “The One True Tool” (as slashdot reviewer) and the means by which I can ask an arbitrary question and get an instant answer.

When presenting DTrace to a new audience, I see my primary goal as creating desire. Nothing worth having comes easily. Getting to grips with DTrace involves a steep learning curve. Before exposing candidates to potentially overwhelming detail, I need to show them why the gain is going to be worth the pain. It’s also useful to underline some seeds of self doubt and insecurity, to establish my authority as the teacher they can trust. So I generally start by talking about complexity.

All I’m going to blog here is one of my favourite complexity stories. It is best done live, with lots of stuff scrolling up a green screen, and plenty of theatrical flare. However, for the purpose of this post I’ve done the UNIX thing and used a pipe into the wc(1) command. I’m sorry if it loses something in the telling, but the base data is still interesting.

I usually start by talking about how complexity has increased during my time at Sun. In the good old days when we all programmed in C it was possible for one person to have a handle on the whole system. But today’s world is very different. In a bid to connect with the old timers, we start talking about “Hello World!”. I then show how good the truss(1) utility is at exposing some of the implementation detail.

We then move on to a Java implementation. The code looks similar, and it is functionally equivalent. Although both the C and Java versions complete in far less then a second, even the casual observer can see that the Java variant is slower. I then start digging deeper with truss(1). First, we compare just the number of system calls, then the number of inter-library function calls, the lastly, the number of intra-library function calls.

This post is really just the raw data, simply to underline the point that todays software environments are a lot more complex than we often give them credit for; and secondly, that we need a new generation of tools to engage with this level of complexity. For added fun, I’ve added Perl and Python data to the mix. Enjoy!

The Code

opensolaris$ head -10 hello.c hello.pl hello.py hello.java
==> hello.c <==
#include 
int
main(int argc, char *argv[])
{
    (void) printf("Hello World!n");
}
==> hello.pl <==
#!/usr/bin/perl
print "Hello World!n";
==> hello.py <==
#!/usr/bin/python
print "Hello World!"
==> hello.java <==
public class hello {
    public static void main(String args[]) {
        System.out.println("Hello World!");
    }
}

It works!

opensolaris$ ./hello
Hello World!
opensolaris$ ./hello.pl
Hello World!
opensolaris$ ./hello.py
Hello World!
opensolaris$ java hello
Hello World!

Sycalls

opensolaris$ truss ./hello 2>&1 | wc -l

33

opensolaris$ truss ./hello.pl 2>&1 | wc -l

118

opensolaris$ truss ./hello.py 2>&1 | wc -l

660

opensolaris$ truss java hello 2>&1 | wc -l

2209

Inter-library calls

opensolaris$ truss -t!all -u : ./hello 2>&1 | wc -l

9

opensolaris$ truss -t!all -u : ./hello.pl 2>&1 | wc -l

232

opensolaris$ truss -t!all -u : ./hello.py 2>&1 | wc -l

31578

opensolaris$ truss -t!all -u : java hello 2>&1 | wc -l

12055

Note: these numbers need to be divided by two (see the raw output for why).

Intra-library calls

opensolaris$ truss -t!all -u :: ./hello 2>&1 | wc -l

329

opensolaris$ truss -t!all -u :: ./hello.pl 2>&1 | wc -l

10337

opensolaris$ truss -t!all -u :: ./hello.py 2>&1 | wc -l

548908

opensolaris$ truss -t!all -u :: java hello 2>&1 | wc -l

4142645

Note: these numbers also need to be divided by two (see above).

Context

opensolaris$ uname -a

SunOS opensolaris 5.11 snv_111b i86pc i386 i86pc Solaris

Conclusion

Of course the above gives no indication of how long each experiment took. Yes, I could have wrapped the experiment with ptime(1), but I'll leave that as an exercise for the reader. When I use this illustration with a live audience, it's generally sufficient to allow the longest case to continue to scroll up the screen for the rest of the presentation.

At this point, I generally move on. Usually, I say some kind words about high level languages, abstraction, code reuse etc. I am not out to knock Java. That's not the point. The point is complexity. I then move on to how DTrace can help us to engage with complexity. I'd do that here, but I hope that I'll continue to be asked to speak on the subject, and I don't want to give it all away here, just now.