Real World Computing
Where did the speed go?
The dtrace programming language (sometimes just referred to as D) is very similar to C in its syntax, but it has useful additions such as associative arrays and aggregations, which are simple ways of combining collections of data points to provide results such as "average", "count" and "sum". To get dtrace to work, it has to be introduced into the operating system kernel. In a similar way to Java, D gets compiled into an intermediate code that can be security checked before execution. What's very clever about dtrace is that it doesn't add any overhead to the system when it's in use: it doesn't impact performance outside of the probes being used. Also, it can be turned off and on in a running system, and can monitor an executing process without that process knowing it's being watched.
I won't bore you with the usual trivial programming examples - "hello world" written in dtrace is no more interesting than in any other language. There are some good introductions and I recommend downloading the Dtrace Toolkit from http://opensolaris.org/os/community/dtrace/dtracetoolkit
To give you some idea of the scope and power of dtrace, we first need to consider the number of probes. On my Mac OS X system, running the command "dtrace -l" says there are 18,156 probes, while on a Solaris 10 system it says there are 44,261. Using just a few of those probes in a one-line dtrace can produce interesting results. Take, for example, this dtrace program:
io:::start { @size[execname] = quantize(args[0]->b_bcount); }
This says monitor the "io:::start" probe, which fires whenever an I/O operation starts. The program creates an array called "size" with quantised values (which means it divides up based on powers of 2) based on the size in bytes (b_count) of the I/O operation. If you run this one liner for a few minutes, as in the screenshot opposite, it will show you how much I/O each program on your machine is doing, grouped by size. Note that you can get inside each individual program, not just where there's a process provider. Using that feature, you can trace each function call in the process, in a similar way to each probe in the kernel.
Two real-life examples
To show the power of dtrace, we're going to give you two examples based on real problems on real systems - a Macintosh running Mac OS X 10.5 and a Sun server running Solaris 10. I've always been a Mac owner and like most Mac owners I tend to hang on to my machines for a long time, so that when I finally come to replace them they strike me as pitifully slow. This is being written on my PowerBook G4, although by the time it's printed I hope a MacBook Air will be in my hands.
Apple ported the dtrace utility to the latest variant of Mac OS X (Leopard) so it was available when my Mac began to run slowly. The problem was related to email: for years, I'd been using Eudora, which worked but was beginning to feel rather tired. Eudora is now an open-source product based on Mozilla Thunderbird (which is very mature) so I thought it was time to move to that, but I lasted about three months before I got sick of it and decided there had to be something better.
I considered going back to the old Eudora, but then decided Apple Mail was a better bet and changed over. Everything was fine at first and worked well with an IMAP server, but then it started to slow down to a point where it ground to a halt - sending an email seemed to take an age and my New Year's resolution to read all my emails was rapidly broken because I just couldn't get to them. In desperation, I decided to apply dtrace to the problem.
