/The gains made by better algorithms almost always outstrip the gains from better hardware./

I've frequently seen where algorithm improvements pay by factors of tens to tens of thousands in CPU time. One change I made in a numerical algorithm improved CPU requirements by a factor of 50,000: from weeks on a super-computer to minutes on a workstation.

Any business-savvy engineer knows that algorithm improvements come at a price: the engineer's time. Striking that balance makes software systems move forward rather than staggering to a halt in bloat and dysfunction. It also helps to use people who actually know what they are doing: knowing how to compile code doesn't make you a software engineer any more than knowing how to spell makes you a writer. End of rant.

On to (rant related) business. On most Web sites, think of how many times a data source will be used to retrieve the same data and produce the same content over and over again. Most successful services deliver a highly redundant amount of information to their users. For example, the JDJ website will deliver this (same) content to perhaps a hundred thousand users. If the servers are overtaxed, customers will experience significant delays or malfunctions.

There are several useful solutions to this. Well configured caching proxy servers come to mind, although server-side scripting make this difficult. Buying more hardware will eventually fix the problem, which may be the correct business solution.

But what about asking programmers to be a little more lazy?

For this article I've included the source for the LazyFileOutputStream. It acts just like a regular FileOutputStream except that, if created on a file that already exists, it /reads/ the data from the file instead of writes it. The stream compares what is already in the file with what you are currently writing to it. If at any point it sees there is a difference in the data you are writing this time compared to what is already there, the stream automatically switches to a write-mode that writes over the remainder of the file with the changes.

The upshot is, if your program generates the same output twice, the output file is unmodified the second time (leaving the original modification date). First, by simply changing FileOutputStream to LazyFileOutputStream, any downstream processing can use timestamp information on the files to check if they need to do anything at all. If the timestamp hasn't changed, then neither has the contents.

But wait, there's more! In addition to the standard close(), the LazyFileOutputStream also supports abort(). This method effectively states "I'm done now, leave the rest of the file alone." The remainder of the file will be the same, even without reproducing it. This means that, if you determine at an early point in the processing of the file that it's going to turn out the same, you can simply abort() to leave it alone. Its similar to the idea of not changing the modification dates on files which are rewritten with the same data, but allows for saving CPU time for the current process step as well as downstream processing..

Certain engines produce part of the template before you can conveniently intervene to decide if you really need to regenerate it. By opening up the output as a Lazy file, you can just abort() early and have the old version, with the the old modification time, around for downstream processing.

Okay, rant concluded and point made: CPUs around the planet are spinning through the same data tens of thousands of times producing the same content tens of thousands of times. Instead of buying great big servers to manage this, a smart caching policy based on lazy file writers and some modification time testing could save some sites that same wild-sounding factor of 50,000. Without having to buy 50,000 new servers.

Anecdote # 1. There is a certain technical advantage to this style of writing data as well: most storage devices are easier to read from than write to, adhering to the 80/20 rule: 80% of file access will be reads, 20% will be writes.. The LazyFileOutputStream takes advantage of that for the many files which are simply rewritten with the same content.

Anecdote # 2. There must be a few curled toes out there saying to themselves, "Why not LazyFileWriter?" There are good technical reasons for the OutputStream: the logic of the data written must be checked in its raw /byte/ format for the idea to work correctly, and you can always wrap this in an OutputStreamWriter, followed by a BufferedWriter, which is what I recommend.

Now I'm even done with the anecdotes. Have a nice day.

• LazyFileOutputStream.java