The author wrote: "I wrote code that correlated a short list in one record with a long list of values that resided in another record, summed values that matche

The author wrote: "I wrote code that correlated a short list in one record with a long list of values that resided in another record, summed values that matched between the two lists, and presented the result. ... It was all very clear and clean code. Unfortunately, it turned out to be horrifically inefficient, though I did not notice this fact at first. It was only later when I decided I needed to be able to perform this operation hundreds of times and produce tabular output to show a visible matrix of results that the failures of that approach became obvious." This reminds me of an approach I took on a recent project, where I wrote a variety of ultra-simple routines to look up very specific numbers and results. These routines would often go out and fetch a rather large file of data, and crunch that data down to the single result the caller desired. All in all, it was a highly inefficient way to do things. However, it was not a problem, because all I had to do was drop in a few caches here and there inside the routines, and voila, the whole thing became fast enough. I found it a very liberating approach, because all of my code looked very "obvious" in its logic. In a few scattered places you see a couple lines of code to look something up in the cache first, but then it drops down into the ordinary and extremely clear logic. The code also had a very nice "lazy", "on-demand", and decentralized feel to it, with no need for a bunch of gnarly and centralized initialization code.