The Perfect Virus principle #4: Performance

As indicated in my post of Monday, 11/22/2010, I am extrapolating Jeff Walker's Principles for the Perfect Application into a discussion of The Perfect Virus. Since Jeff's monograph on the subject did not anticipate stealth or suicide mechanisms, any errors or lapses into stupidity are solely my additions and should not reflect poorly on what I consider to be the biggest single contribution to software application design since the invention of computers. And Jeff, thanks for giving me permission to do surgery on your baby.

THE PRINCIPLE OF PERFORMANCE: The Perfect Virus provides high performance by minimizing memory usage, instruction path lengths, and database operations within itself and within its spawn. Ideally, the virus will metamorphose (discussed in greater detail in principles # 5 through 10) into tight, machine-language code.


I've always adhered to the philosophy that genius doesn't emerge from committees, and that no greater performance can be achieved than by having one genius programmer coding in assembly language. Further, while performance isn't the Holy Grail of virus creation, it's certainly high on the list. Get in and out quickly, cover your tracks, and lay a few eggs so you can snuff yourself if necessary. 


Back in my days doing guerrilla warfare for Larry Ellison and Oracle, we quickly determined that performance was indeed the Holy Grail of market domination, assuming that all other factors were equal. In Oracle's case, businesses and their customers didn't want to wait around for answers. And in the ultimate bit of cleverness, we put a non-benchmarking clause into the Oracle customer contracts, wherein they were specifically forbidden to publicly disclose benchmark comparisons (Tom Siebel took this one step further after he left Oracle and started Siebel Systems, where customers were contractually forbidden to say anything bad about Siebel products; their only recourse was to get their money back if they were unhappy). Thus Oracle had complete control over the benchmarking competitive process. That's how important performance was and still is in the database world.


As far as The Perfect Virus is concerned, performance is a matter of survival. Quick is good. Slow is very, very bad.


Also, minimizing memory usage is best achieved in tight machine language. As indicated in yesterday's post on Self Awareness, I once wrote a complete real-time operating system in around 700 12-bit words of memory. I'm amazed how piggish today's operating system and applications software is. The prevailing attitude seems to be that memory is cheap, so why be clever? Back in "the day," we used to brag how small we could make things. The record for ingenuity was using only three machine language instructions to zero all of memory. Just a few more instructions to overwrite all hard drives. Well my little army of cyber privateers, small is not only faster (both in terms of load time and execution time), but small makes it easier to hide stuff (memory-to-clock time is something I'll cover in greater detail in principle #14: Stealth).