Writing code for performance optimisation

We all know the call from a client telling you that the software has become so slow, it’s unusable. Yesterday it was fine, but today it is a disaster. It’s not that the code has a life of its own, but reaches a tipping point where performance degradation has eroded to the point of unresponsiveness.

We know we need to optimise the performance, and need to dig into the code to resolve. But first, what would be the aim (except for the obvious "make it faster")? Optimising performance of software entails the following:

• To allow rapid execution
• Operating with less memory storage or other resources
• Working more efficiently

Levels of Optimisation

The performance issue could be in anywhere in the system, yet it makes sense to split the possible issue into different levels where the issue would be. For this article, I have split it into design level, algorithms and data structures and source code.

Design level – on this level design/architectural choices are made. For example, if a system has a strong dependency on network calls, it is best to optimise the solution to as few as possible calls over the network, yet still getting all the required data. 

Algorithms and data structures – The way that data is persisted in a database could affect the SQL execution paths as well as sorting and filtering algorithms. It is therefore advisable to plan these structures well before implementation.

Source code level – Some languages do not have automatic garbage collection (disposing of used objects/code). Another example: x ^ 2 can be written as x * x. As systems could grow exponentially, this could potentially cause a great headache.

Coding for performance

Debugging is an essential skill when it comes to coding for performance. The art of eliminating possible causes of issues will help us in finding the true root cause.

When writing software, it's important to code with the end in mind. Keep the following in mind:

• Don't over-engineer the code to try and fix performance issues before they happen
• Delaying performance optimisation until it becomes a problem is not an excuse for writing terrible code
• Include performance measuring tools and debug helper libraries early on in a solution. This will help in finding issues early.

The trade-offs for performance optimization

Even though reasonable precautions can be taken to avoid slow code, it’s not always the best solution to start optimising code prematurely. Optimising code before this is an issue can cause unnecessary delays in delivery and wasting precious time.

Some code best practices could actually slow down code. For example in large systems loosely coupled code paired with external libraries implementing dependency injection could contribute to a slow system. 

Conclusion

Careful planning and consideration need to be given when starting out on a project. The architecture, infrastructure and technologies need to be chosen carefully, to align with the goals of the software.

Once an issue with performance surfaces, it needs to be investigated, the root of the issue determined and the issue resolved.

Though this sounds like an easy task, it’s not necessarily something quick. 

Simply be effecitve.

The full article can be found here:

https://effectify.co.za/2020/09/14/writing-code-for-performance-optimisation/