Justin Jamesasks why nobody seems to care about performance anymore. He talks about how the performance hit you get from using a “slow” language directly translate into increased hardware and electricity costs just to maintain the same kind of performance you would have had if you’d used a “fast” language or spent more time optimizing your code.

All his points are good, but they’re also all irrelevant. You see, for most applications the performance hits you get from slow languages or non-optimized code just don’t matter. Your system will still be responsive enough that no-one will be bothered. People don’t care because it just doesn’t have any noticeable effect on the end product and some languages make coding far more enjoyable and productive. Their productivity gains far outweigh performance hits that are almost unnoticeable by end users.

This is exactly why Ruby on Rails is kicking ass and taking names. It’s not terribly performant. Ruby is unquestionably a slow language. The huge infrastructure of RoR makes it even slower… but it makes developers incredibly productive and the resulting sites are “fast enough”, especially if you take the time to host them with the correct tools.

Before I started working at Akamai I was one of those people who just didn’t care about performance and you would have been hard pressed to convince me that coding for performance really mattered for anyone who wasn’t coding something like a router or OS Kernel. That was until I started being presented with numbers that just blew my mind. Our group is currently just looking at a very small subset of the data that flows through Akamai’s pipes and we still have to process hundreds of millions of log lines per hour. I remember amazed by a graph showing Yaws handling 80,000 concurrent connections per second while Apache keeled over at 4,000. “80,000!” I thought. “With performance like that we could blow through those logs. Now lets see… Hundreds of millions divided by 80,000 is…. oh… not… even… close.” Erlang could be an incredible tool for some of the tasks here but even a language with incredible concurrency support like Erlang isn’t, alone, enough to deal with the sheer scale of things here. You have to care about performance at Akamai. It’s not just what we sell to our customers, it’s the only way for us to survive what we sell to our customers. I still believe that for most developers language and framework choices are more important that worrying about performance, but now I understand what a sheltered view of the world I had and how that view fits into the larger world. Joining Akamai combined with a recent series of small performance related events has opened my eyes to just what a dramatic choice it can make when you do start taking performance into account. Yes things are generally “fast enough” but you will kick your competitors asses when their products are “fast enough” but yours is instantaneous. “Lightning fast” is a more compelling feature than you would ever guess. It’s pointless market-speak in a feature list but once you experience it it’s damn hard to walk away.