I realised that my previous post talks more about what you should do and less about why you should do it. I’ll try to rectify that.
For me the important ideas were:
- Optimising code can make it much much faster.
- Focus optimisation where it makes the biggest difference.
- Save time and complexity by only optimising when you need to.
I don’t think the first point is in question. The original python code for this problem may have been terrible. It’s not surprising it could be improved. It was impressive when someone got the execution time down to 1 second. However even that was not the end and it was improved a factor of 1000.
What about the other points? Why am I suggesting you do less optimisation?
Optimised code is more complex
I think that most optimised code ends up being more complicated than an unoptimised version. This could be measured directly in extra lines of code, it could be an algorithm that you must understand to write the code, or it could be about extra dependencies on data or other systems. If you can get away without this complexity the code is less likely to have bugs and will be easier for other engineers to work on.
Optimisation can be subtle
Execution time depends on a lot of things: the original source, how the compiler optimises the code, how the processor runs the code, how many caches there are and how big they are. It’s possible to look in depth and take advantage of all of these. However the first time you write some code there probably isn’t time to really look in depth. Using a profiler later on allows you to see what is affecting performance and target those things.
Algorithms make the biggest difference
Optimising the code, but not the algorithms, can improve the performance of an app by a some factor. That means for a small test you might make the code 10% faster and for a large test it would also be 10% faster. However with a better algorithm you can improve the time complexity. That means for a small test you might make the code 10% faster but for a large test it would be 50% faster.
Testing code in real situations
When you originally write code it may not be run a realistic situation. It could be run by unit tests, in a test harness, or with smaller test cases. This often necessary to get things working to start with. The code necessary to run real tests may not even exist yet. However the performance characteristics might be completely different for small and large test cases. By waiting to test in real situation you can make sure to optimise the right things.
How to balance optimisation
In Matt Parker’s original situation there were two times to think of: how long did it take for the search to run and how long did it take to write the code to run the search. We’re probably all in a similar situation: we have performance expectation for the final software but only have limited time to work on each new feature.
For me the first step is to get something working correctly. If it’s not working then it probably doesn’t matter if it’s fast or not. Once it is working you can start thinking about how to make it faster.
Leave a Reply