Why the Mailman Cuts Across Your Lawn
and Other Programmers' Shortcuts
  

Why does the mailman take a shortcut across your lawn every day when there's a perfectly good brick walkway? Well, he's not being perverse, taking pleasure in trampling grass that you're struggling to keep green. Nor is he particularly lazy. Rather, he simply is being efficient because he has noticed the power of tuning repetitions. This can be almost instinctive, as in the mailman parable, but in more technical applications, an analytical approach may yield surprising, and impressively useful, results.

I'm going to give you an example from computer programming — but don't worry, no actual computers or computer language are involved. Just a fairly plain-language example and a smidgen of logic. Then we'll get back to our everyday mailman.
  

Suppose you are responsible for a computer program which runs thousands of times per day, perhaps handling each transaction from a bank's network of automated-teller machines or something like that. It's a complex program in detail, but not in purpose. It just verifies the information from your ATM card, notes how much you're depositing or withdrawing, and updates your balance. If you want a second transaction while you're at the ATM, the unseen program smoothly wraps up your first transaction and goes on to the next.

No problem, right? Your ten minutes at the ATM has been well spent.

Wait — ten minutes? That's not acceptable, not to the customer at the machine, nor to the customers standing in line behind him, nor to your boss who doesn't like explaining to his bosses why your program runs so slowly that customers are always peevish, perhaps even switching banks.

Clearly your task is to make this program run more efficiently, as much faster as possible. As is common, this program has been around for years and has accumulated many thickets of code which could be eliminated, and developed wayward logic paths which could be untangled. So after long hours of clearing the thickets and straightening procedures, you've made the program run twice as fast. Very good!

Your boss says that five minutes per transaction is unacceptable. Would you like to stand at the ATM for five minutes for each simple deposit or withdrawal?

Well, no. But you've just about rewritten the whole dern program; what more can you do to it?
  

The answer is to analyze and tune repetitions, that is, look at how many times the various parts of the program, its sections and sub-sections of code, are executed per transaction. If you don't have a software tool that does this, you can scatter one-line counters throughout the program and compare their tallies for a typical single execution of the program — I've done it both ways.

Here's that (fairly) plain-language example I threatened to provide:

Code-bloc 1, setup
  50 lines of code, executed once per ATM visit

Code-bloc 2, verify ATM card
  20 lines of code, executed once per ATM visit

Code-bloc 3, verify password
  10 lines of code, executed once per ATM visit

Code-bloc 4, inquire type of transaction
  5 lines of code, executed once per transaction

And so on. The next one is interesting:

Code-bloc 10, acquire customer's records from database
  20 lines of code, executed once per transaction

... But that isn't quite right. The function of Code-bloc 10 is done just once in theory; but in practice, your program has to keep pinging the bank's busy database until it can get a grip, or "lock", on the customer's records and perhaps ledger records so simultaneous updates won't step on each other and destroy data. So Code-bloc 10 loops, repeating over and over until it has these records secured so that further code-blocs can verify the balance, safely update it, and so on. How many pings might be required? At a busy time of day, let's say it's a thousand or ten thousand executions.

At American Honda I once saw a two-year-old program misbehave with an undetected bug in the original code, encountering for the first time one situation that hadn't been tested for. Very simple: trying to delete a database record which already had been deleted. This caused a loop that would not quit, as the relevant code kept executing over and over, trying and failing to re-delete the record. On that occasion the program keen-mindedly re-tried the deletion six million times before the computer operators noticed there was something wrong, that a single program was hogging the entire huge computer system; and the hard-working program got in another million delete attempts before it was knocked offline.

Back to Code-bloc 10. Sure, its function happens only once per customer's transaction. But its execution, at a thousand or ten thousand times per transaction, is where our program actually is spending its time.

Removing a single line of code from Code-bloc 10, executed in practice a thousand or ten thousand times per customer, probably makes our program run faster than taking out whole blocs elsewhere which really are executed only once. This is optimizing the code by means of tuning repetitions. It is very powerful.

Of course, patient and even imaginative work often has to be done to clear the thickets of code and straighten wayward paths of logic, before you can run an analysis that you can make sense of. But it often pays in the long run.
  

Returning to our mailman, whom we last saw making a beeline across our lawn. He's sorted the mail, and driven to his route area, and afterwards will drive back to the post office again. These activities take time, but each occurs just once per day.

Let's say that the mailman saves only ten seconds by his shortcut across your lawn. Hardly worthwhile, to risk the quicksands and bear-traps. But let's look at his entire route. Routes vary with the terrain, whether business or residential or rural, and so on; but let's assume 200 houses that our mailman delivers to. And let's assume that a couple of dozen of these offer shortcuts to the busy mailman, averaging ten seconds each.

240 seconds, or four minutes total: by taking each of these 24 shortcuts, he saves four minutes per day. If he delivers his carrier route on six days per week, that's 24 minutes per week. If he delivers 52 weeks a year, that's 1,248 minutes, or 20.8 hours in a year. For someone who spends a great deal of his life walking, that's a fair number of hours that he'd rather be sitting with his shoes off and feet up.

In a nutshell, or a mail-sack, that's the power of tuning repetitions. You do it yourself every time you go to the grocery and buy twenty items, rather than make twenty trips for one item each. Balancing these numbers is a big part of making everyday life efficient, as well as our now much-faster computer program. Being aware of the principle may yield some surprising and helpful results now and then.

© 2012 Robert Wilfred Franson