(technical post ahead)
I wouldn't have thought, that I link to a MSDN article that soon. But, then it is a Microsoft article about performance (!) and anyway, my standard excuse for bad code has always been 'performance issues' :-)
Writing Faster Managed Code: Know What Things Cost by Jan Gray. Interesting read, even if you avoid .NET. And don't miss Tim Bray's comments.
"I promise I will not ship slow code. Speed is a feature I care about. Every day I will pay attention to the performance of my code. I will regularly and methodically measure its speed and size. I will learn, build, or buy the tools I need to do this. It's my responsibility."
I think, that it is useful to once think about how your programming language actually does all those nifty things under the hood. Not only to be aware of performance killers, but I often feel that this understanding gives me more comfort in what I do - and depending on the feature in question, seeing through levels of abstractions is very helpful when tracking down a bug.
Very interesting are his numbers on CPU cache effects towards the end of the article. Understanding how the memory is managed by your runtime environment will get you a handle on which data structures and algorithms use your CPU's cache effectively and which don't. While working on our search engine we encountered several significant optimizations, often rather nontrivial, with often slightly more complex code as a result. The search engine is written in C, keeping a handle on such issues through abstractions is not easy. But having the CPU cache in mind and getting these things right is in our experience one of the most important and generally underestimated factors to keep in mind if you work with a lot of data and your goal is to write software with good performance.
People working on compiled languages on linux might want to check out Valgrind, which is not only one of the most useful debugging tools if you do your memory management yourself, but also features a nice cache profiler.
Update: Christian Langreiter links two interesting articles about the important role of the L2 cache: Treating DRAM as a paging device and Memory Hierarchy and Data Locality.
Posted by seefeld at June 12, 2003 19:42