The Myth of Speed: Why Compiled Code isn't Faster on the Web

It is a standard argument that compiled code is always faster than interpreted code. This is of course completely true from a technical stand point, however the meaning of speed in this context is valueless. Speed, when you talk to a programmer, means something very different than it does to anyone else; and this difference is a stone cold killer.

Why Programmers are Wrong

When programmers talk of speed, they are talking about machine time. They are ultimately talking about microseconds. Microseconds, when repeated, add up to hours and hours of wasted time. Increasing the Speed of a process reduces all kinds of hardware costs and reduces the wasted time of users, right? Well, not really. There was a time when this held true; but these days the most costly portion of the development process is the programmer's time.

Let's back up. Certainly a faster program will save the user time? If we were talking about a desktop application, that is absolutely true, especially when we talk about speeding up a process that will run a million times as the user waits. One millisecond of saved time in a process turns into one million milliseconds, or 17 minutes. However, our Web applications NEVER do these kinds of tasks. If they did, those applications wouldn't get used. Users on the Web won't wait 17 seconds, let alone 60 times that. Web apps work differently. They poll a database for the 10 records that will be shown, and save the processing for the next 10 to the next request. 10 milliseconds extra won't matter, that is 30-40 times faster than you can blink your eye. Saving that millisecond here won't save the user any time at all.

However, saving a millisecond for each of a million customers will still save 17 minutes of machine time; so it is still a cost saving measure! But what costs more; the less than 0.1% more hardware you'll need, or the time of the ~$100,000 a year programmer? Is it worth it for spend a day? A week? Is 0.1% of your hardware worth $2000? In some situations, yes; in most, no.

So what does this have to do with compiled code?

Compiled code can be 1-10% faster than Interpreted code. 1% faster if your language intelligently caches the compiled version of often run code, and it is coded to take advantage of that caching; 10% if you are writing messy code in a language without such caching. This sounds like a no-brainer but you must remember that this is 1-10% of only the processing time. It ignores the time consuming parts of the Web equation entirely.

First, the user clicks on a link sending a request to your server, this might take 50-250 milliseconds. Next, the server will decode that request and start the process of running whatever program is needed to generate the response data, here is where your code goes; it should ideally take less than 1 second to process, that's 1000 milliseconds. Finally, that data needs to be sent across the internet to the user. If that user has a 1Mb connection, and you are transferring 650KB of data that is around 5050-6250 milliseconds. So the total time is roughly 5-6 seconds

If it were 10% of 5 seconds, it would only mean .5 seconds less time, but it is 10% of the 1 second of processing time only. We are talking about such small amounts of user time here that they are inconsequential.

But it gets so much worse

Compiled code is more time consuming to develop. It has a lot to do with the nature of the specific languages, but in general an interpreted language can get away with a variety of tricks that a compiled language will be too rigid to support. For example: the weak typing of PHP versus the strong typing of .Net; while weak typing can open new security issues if not taken into account, it also lends itself to very quick and flexible coding, especially if the language has a large quantity of only subtly different types (I'm looking at you, C#).

Where should we spend our programmer's time?

On the Web, the most important place you can spend your time is between the server and the user. Reduce the number of connections, the size of files, and the need to request them again. Use AJAX or cron jobs to avoid making the user wait for things that are slow. If you want to reduce hardware, forget optimization for milliseconds and invest in intelligent caching, or ideally memory caching. Avoid repeated processing wherever you can. It is betterto waste time removing all the white space from your output html, css, and js than it would be to use that programming time to speed up a process.