The Performance and Tuning Doctor by Sturnus

"Memory is cheap"

After many years' working in performance and tuning, I still remember that line. Let me give you some essential context; the full story was basically this:

1. A customer had a problem with the performance of a particular system
2. A one-off addition of extra resources (in this case memory) would resolve the issues
3. The extra memory would cost less than paying me to speed up their software
4. Economics won

They were right, of course, and there was nothing I could do about it. In the business world, you are bound to eventually come up against economics.

Fortunately for my career, there were only two occasions when the argument against paying me to improve software performance was so devastatingly compelling. I've already given you the first time; the second was when my failed-to-become client stated that no-one actually cared about the performance of their slowest report. It would start on a Monday; everyone would get on with other work, and whenever it completed - a day or two later - they would process it. I couldn't argue with that one either.

So there we have it; if no-one cares about the performance of your applications, or a cheap hardware fix makes them go away - you're all set. You don't need to read any further.

Unfortunately, these aren't the only scenarios. Chances are you'll be in the same boat as all but those two of my previous customers: someone cares, and there are no cheap hardware fixes.

Let's start by looking at why someone might care about your software performance.

Users care

Most software has a user somewhere. Whether it's someone waiting for an ATM transaction to complete, a web user trying to upload a video, or a mobile user trying to share a post. Somewhere there's a real person, impatient for something to complete. Users care a lot.

In the mobile world there's even more to think about; it's not just about timings. The harder a mobile device is working, the more power it's using, and the shorter the battery will last. If there's one thing mobile users hate more than a slow app, it's their battery dying because your app drained it for them!

The tricky part is actually to gauge dissatisfaction: measuring customer retention can be hard enough at the best of times, but determining how many of them go elsewhere as a result of slow software is not at all easy. In reality, an exodus of customers is not the first time you'll find out that something has put them off - you'll probably get plenty of feedback long before this happens. Whether you choose to act on it, of course, is up to you.

If you are in the business of creating mobile apps, you have a much more direct way of getting feedback. The moment an app gets in the hands of users they care very much about how well it performs, and they're not afraid to tell your about it. In this age of swipe left and swipe right, any slight inconvenience or irritation to the user will result in a bad review and an uninstall faster than you can say "what happened?" User interface a bit stuttery? Delete. Download takes a few seconds too long? Uninstall. Your app is rarely the only option a user has, and you're unlikely to get them back. Believe me, users are brutal.

There's a certain injustice about all of this: you won't get a peep out of your users if your app runs like greased lightning, but the moment someone thinks it's a bit slow, that's it ... game over. What can I say - life's just not fair.

The conclusion is simple: as soon as there is someone in the chain who cares about how fast your code is, you need to too.

If, on the other hand, you don't particularly care about users - there may be someone else that you do need to care about.

Finance Directors and investors care

Hardware may be cheap, but it's not free. So if dissatisfaction from your users or employees isn't enough to sway you, then how about from above?

With the proliferation of cloud services, upgrading to a better performance package is the modern equivalent of upgrading hardware. The difference now, of course, is that this is no longer a one-off cost. The economics have changed.

Indeed, the cost of improving software performance may now be attractive, when compared to the on-going, indefinite cost of a more powerful server or cloud service package.

Now we have a couple of reasons why you might actually care about performance, the next question to address is this: why should you work on the software rather than simply upgrade the hardware?

Adding resources might not work

An organisation I worked with recently often had issues around he performance of database queries. At one point they opted to upgrade to a more powerful, more expensive "big new shiny database" to address those issues.

What happened? Nothing. It made no difference whatsoever. It turned out that the queries were bottlenecked in a way that upgrading the server package didn't help. It was an expensive lesson, but it also highlighted an often-overlooked risk: you may not actually know whether a hardware upgrade will improve things in advance of paying for it. Economics won't help you this time.

Using another example, around about the time I stopped working mainly in the database arena, fully in-memory databases were becoming popular. More database vendors were offering commercial solutions, and it was seen as the inevitable end goal for systems where more memory provided for improved caching, and thus better performance.

Everyone simply assumed that once everything was in memory, that things would be dandy, but this isn't always the case. The problem is that once you've got everything in memory, there's nowhere to go if you've still got a slow system. Sure, since you'll probably be CPU-bound at this point, you can try upgrading your processors, but then we start hitting a whole realm of trouble in terms of unidentified bottlenecks and diminishing returns. When you starting throwing hardware at the problem, it starts to look a lot like guesswork.

The biggest lesson I learned in over 20 years of doing performance work is that the most dramatic performance improvements you'll see are with improved architecture, data structures, and algorithms. Everything else is pretty much tuning.

Hardware isn't always under your control

Back in the 'good' old days when everything ran on a server, upgrading resources was relatively easy. When client-server came along, things were harder, but still manageable: servers could be upgraded as before, but upgrading client machines that were spread around an organisation took some planning and coordination.

But once we got to web sites that performed lots of processing in the users' web browser, or mobile apps, suddenly things became much more difficult: most of the hardware doesn't belong to you; you have no control over it. Sure, you can tell users that there is some kind of minimum hardware requirement, but that doesn't mean they're going to listen. Also, every class of hardware that you don't support is another group of users or customers that you're missing out on.

Mobile, of course, is the biggest headache. The problem isn't quite as bad for iOS devices, since there is a limited variation in device capabilities. Android devices, on the other hand, come with a vast array of features - processors, graphics performance, and memory. Anyone who's ever developed an app and tried to get it working on a memory-challenged Wildfire S will be painfully aware of this. I'm not the only developer who bought one of these phones just for testing: if you could get an app to work on a Wildfire S, it would probably work on anything!

The bar is certainly higher these days with regard to device specs, but when there are a broad range of client devices, all of which are out of your control, you need to work on a lowest common denominator basis: performance needs to be good on the worst device.

You might not realise things can be improved

I'm throwing this in at the end, because I'd like to leave you pondering a question.

I once worked on a membership subscription report for a customer based in Sweden. The report took between 25 and 35 hours to run, and basically executed the same stored procedure (- a stored procedure is code that is stored and runs on a database system), which calculated subscription amounts, for thousands of members.

I rewrote the calculation stored procedure to make it more efficient, and the report subsequently completed in 2.5 - 3 hours. When one of the client managers heard about this, he asked "how is such a thing possible?"

I hope I've left you in no doubt as to why software performance is important. Now I'd like you to think about this: could such an improvement be possible with your applications? Wouldn't it be interesting to find out?

Back to top