Do developers care about performance anymore? I seriously doubt it, at least for the vast majority (over 90%) of developers. A few weeks ago, I had an interesting talk on the forums here about performance. I compared some simple Perl code to equivalent C# code for text processing speed. The numbers were fairly inconclusive (Perl was about 25% faster) due to the fact that I most likely was hitting disk limitations more than anything else. With some tweaking, I can fine tune the test to time only the processing, and pipe in data cached in memory to take the disk speeds out of the equation, to do a raw performance measure. What struck me most about this whole thing was that it has been quite some time since I talked to another developer about performance of code. Sure, when talking about coding, a smart developer can play the, "Ah, but that is so slow!" trump card. But rarely do we ever talk about performance plain and simple.
This weekend, I became extremely curious about some aspects of the ASP.Net Application object and how it works. Doing some research into it, I ended up doing a lot of reading about the caching options that ASP.Net offers. I knew that there was this cache object and such, but I never really looked into it, assuming that it would be fairly Mickey Mouse, like much of the built-in ASP.Net objects. Boy was I wrong! Despite the huge performance gains that this system can deliver, it truly stunned me that I have never once heard of anyone use it, show how to use it, or even mention it. It even supports the ability to have SQL Server notify the cache that a data source has changed and that the cache should be invalidated; it also provides a callback mechanism so that you can trigger a re-caching if desired. Pretty nice stuff!
This begs the question: Why does no one seem to care?
OK, let's get honest for a moment. I am talking about ASP.Net here, which is not known for being a monstrously fast system. .Net is fairly close to native code, probably a 10% - 20% (depending upon what you are doing) hit compared to C++ for most programs. On modern hardware, and for most applications, that hardly seems like much. And, yes, the interpreted languages that used to get knocked for being "slow" five or ten years ago (Perl, Python, and PHP) are fairly swift in comparison to today's managed code systems of today (.Net and J2EE). But in a Web server environment, or any kind of server environment, a 10% - 20% reduction in speed will equate to a 10% - 20% increase in hardware needs (actually it's a bit more because each server loses some resources to the OS, and even more to the overhead needed if clustering is used), which means a 10% - 20% increase in power bills, and a 15% - 25% increase or so in IT support time (particularly for deployments). For a large application (particularly for a SaaS/ASP provider with a huge application), this can be millions of dollars. But most companies today choose that cost rather than developer time. After all, developing in any modern framework is still faster than writing C++ code.
Even so, sloppy coding or not taking advantage of built-in speed boosters like caching is just throwing money out the window. Performance is a lot like multithreading — there are no hard-and-fast rules, but there are a lot of firm-and-speedy guidelines. There are a lot of tradeoffs and compromises. And unless the programmer knows what he or she is doing, they stand a very real risk of making things worse.
Sticking with the caching example, a bad developer can cache too much, increasing the overhead to the point where non-cached performance suffers. Or, a bad developer can improperly cache, delivering out-of-date results where real-time results are needed. And a bad developer can cache data that constantly needs refreshing or should not be cached, which uselessly increases overhead. And so on.
It is not about to cache or not to cache. Here's what I'm really wondering: Why do so many developers not seem to care about being ignorant of performance-increasing techniques? And, more bizarrely, why don't the bean counters care? The bean counters are the bane of every developer. They're the ones who tell us that we can't have eye-saving task lighting and must make do with cheap overhead fluorescents. They're the ones who sit us in $25 chairs with $5 keyboards and $7 mice and $100 monitors. Yet, they apply zero pressure whatsoever to reduce the real operating costs of their server room by 10%, 15%, or more. I find this attitude bizarre. Granted, many performance refactorings can take nearly as long as writing the code the first time, only to eke out a marginal improvement. And yes, developer time is expensive. And, of course, an hour spent refactoring working code is an hour not spent incurring billable hours.
The tradeoff between time and value is known as ROI. How much time you can afford to put into performance enhancements is largely dependent upon the size of the project. And there is zero excuse for coding practices that are known to slow code down, like not calculating loop ending conditions in advance, forcing a recalculation on each loop. A good developer will write code that runs fast by itself, and outside items like external caching libraries, multithreading, and so on, can be added later. But a poor developer writes sloppy, slow code to begin with, and then chirps up with the "throw hardware at it" excuse or blames the language/sys admins/network engineers/framework developers/the latest OS patch/whatever. So, please, try to be a good developer. Learn some healthy habits that help your code run faster and reduces the need for tweaking, and get to know what your options are for boosting performance. In the tough world of development, a developer who has this knowledge and approach to programming stands out in the pack.
Justin James is the Lead Architect for Conigent.