Speed of execution or software performance
This is the second post in a series of posts treating software quality attributes. Unless your only concern is the performance of your software I do recommend that you start by reading the first post of this series.
The performance of a software is quite simply how fast the software does it’s job. It is commonly measured in response time, that is how long time passes between the initiation of a command until the command has been completed. Performance is often measured in seconds or milliseconds in combination with workload, that is how many concurrent requests the system is handeling. That is the simple part of thinking about performance.
How much is enough?
Knowing what level of performance you need is key. Describing the performance requirements for a reasonably complex piece of software can be a little challenging. The number of operations that the software does offer might be very high. Does all these operations need to execute at the same speed? Answering yes to that question might be tempting, but not always a good idea. First of all, optimizing your system for performance costs time and money. Is it really worth all that time and money? Where is the business benefit for improving performance? In some cases it is easy to see. If you have a customer facing website that is used for selling merchendise you do not want the customer loosing patience and move on to a competitors website. Another example is high-frequency trading. If you designed a system to buy stock that you know someone is about to buy just to sell it to them a few microseconds later with a small profit coming your way you do not have any business unless the speed of execution is fast. An example of something that might not need high execution speed is running a monthly report that is supposed to be presented five days after the last day of the month.
To successfully implement the performance your business needs you should find out what speed is good enough for your business to reach it’s goal. And to do that for if not all then at least the most important functions of the system. The next step should be performance testing. Creating these tests can be done in many ways, ranging from implementing the test in code by yourself all the way to using sophisticated performance testing products. Regardless of the way you implement these tests it is important to be able to run these tests quickly and easily so that you get feedback on how well the system is currently performing since that might change as time goes by. If your tests shows that the performance requirements are not met you need to start thinking of performance optimization.
When it comes to optimizing performance there are a couple of big mistakes to steer clear of. The first one has to do with where in your system you experience the performance issue. The test that shows that the execution speed of a function is too slow is not enough to show you where – exactly – in your system the cause of this issue lies. Let’s say you create a lot of extra code to optimize the performance and manage to improve the performance by 1%, far away from the 25% improvement you were looking for. One reason for this poor outcome might be that the part of the system that you chose to optimize might not be the part that was running slow. The solution to this problem is of course to find out what exactly is causing the performance issue by running more tests. After you pinpointed the bottleneck you have a much better position to start working from.
Another problem with performance optimizations is that it might drive quite a lot of complexity in your system. As said by Bill Harlan:
Optimizing correct code is easier than correcting optimized code.
The important point in Bill’s eloquent one-liner is that when the code is optimized it generellt becomes more complex and harder to work with, therefore Codeworks optimization might seriously impact other quality attributes with maintainability being dead center in that risk zone.
How to fix performance issues
You may have noticed that although the title of this post uses the phrase software performance I often use another phrase in the text: System performance. The reason is that the performance issue that you have discovered might not have anything to do with your programming code. Some common reasons for poor performance are:
- Network issues
- Slow hardware
- Operating system problems
- Multiple software processes competing for hardware resources
- Poorly indexed data
- Too little or suboptimal data caching
- Slow running code
Having slow running code at the end of this list makes a lot of sense as optimizing code is expensive and even expensive multiple times. Optimizing code takes time, and very often optimizing code makes the code more complex and therefore more expensive to modify in the future.
So, your first inclinations should be to check for network issues, hardware issues and infrastructure issues (such as operating systems, databases and caches) – not to try to optimize your code. Unless, of course, your tests have pinpointed a problem with your code.