How to Make Things Faster

Chapter 27. Measurement Intrusion

Once at a packed 5,000-person convention hall, my friend Tom Kyte answered a great question from the floor: “Tom, the Oracle Database has a lot of performance instrumentation built into it. It’s always on, and so it’s always using resources that my application could be using to go a little bit faster. How much overhead does all this instrumentation add to our response times?”

Tom thought for a few seconds, and then he answered, “Probably negative ten percent. Or less. Maybe even negative twenty or thirty percent.”

He paused to give his now-vexed audience a moment to ponder what a negative percent was. Then he continued, “What I mean is that the database is at least ten percent faster—maybe even twenty or thirty percent—than it would have been without its instrumentation. Running that particular ‘overhead’ has helped our kernel developers make our database code faster and faster over time.”

The performance penalty that a program endures when it measures itself is called measurement intrusion effect. Ideally, performance measurement should be so lightweight that its intrusion is unnoticeable. As it so happens, people are accustomed to response time fluctuations of ±5% or so from their programs anyway,^1,2 so if tracing costs less than 5%, people tend not to notice it.

But tracing doesn’t have to be unnoticeable to be valuable. Even if tracing were to cause a one-hour program to take two hours—if a trace teaches you how to make that one-hour program ...