2011/2/18 Rob Pike <robp...@gmail.com>: > The more you optimize, the better the odds you slow your program down. > Optimization adds instructions and often data, in one of the > paradoxes of engineering. In time, then, what you gain by > "optimizing" increases cache pressure and slows the whole thing down. > > C++ inlines a lot because microbenchmarks improve, but inline every > modest function in a big program and you make the binary much bigger > and blow the i-cache.
I think what I've been trying to say in this thread doesn't clash with anything that you, Erik, or others have said. Understanding the system, the complexity you are introducing, and carefully measuring the net effect are all important parts of the optimization process. You can't just switch from one data structure to another. Skip lists are a really great example: they have really amazing properties, but you trash your cache when you use them, and gathering entropy to determine where a node is placed is *not* cheap. In the end, an optimization that slows things down is not an optimization at all. You can't do it if you don't understand what you're doing, and you don't understand the overall effect. I don't think that Linux's gettimeofday(2) optimization falls into this category, though I do think that some of the similar optimizations they've done using the same approach do. In this specific case, it is an easy optimization that is cheap and works quite well. It provides measurable performance improvements in the general case, as well as in special cases. As mentioned before, people who need more accurate times can still use rdtsc. > -rob --dho
