How to Make Things Faster

Chapter 25. How Much to Trace

You want your profile’s bottom line to match the experience you’re trying to observe. It wouldn’t be good, for example, for your waiter to tell you your bill is $100 but then hand you a receipt for $20. You’d be left unable to explain 80% of your expenditure, which wouldn’t bode well for your reimbursement aspirations.

Likewise, if you know that a user waited 100 minutes for an order confirmation number, then you don’t want a profile that explains only 20 minutes. But in fact it might be enough.…Which is good because it’s not always possible to get exactly the trace data you want.

In the Payroll story, for example, we asked when our client would next be running PYUGEN so we could look at it. The answer was that we could look at it now, because it’s already running. We could have insisted upon a “perfect” trace of a fresh new PYUGEN execution, but instead we enabled tracing for a PYUGEN process that was already running. And what we learned worked out just fine. (By the way: it’s a highly desirable feature for your tracing function to allow you to trace a program without having to restart it.)

So, how much of a program’s execution do you really need to trace? Not always the whole thing, as it turns out. Imagine a program that last month ran in ten minutes (0:10), but now it takes eight hours (8:00). Do you really need to trace the whole eight-hour execution to learn why it’s not running in ten minutes anymore? You don’t. If you know how long a program ...