Less code does not mean faster code

[mistrc]

I wanted to start this thread to bring up the topic of getting code to run faster. After all when it comes to lowering the SCI score of your application, it is a critical point. The less time your code takes to execute, the less energy it will use and hence the better it will be for the environment.
Now while there are a number of ways to get your code to run faster, like change to a different language (e.g. shift from python to Java) or changing the architecture of the application (e.g. removing needless separation of parts of the application from separate microservices), both of which are topics in their own right, I'm focussing on the idea that I've seen a few times that suggests that less code is greener code. If there is agreement that it is not less code but faster code, then we should create something that helps focus the minds of developers, like a set of questions that a developer can ask when looking at code.

Of course I did not say greener code in the title, because there is a nuance here. When it comes to the code you write, there are two costs

1. the time it takes to write the code, including the testing of the same, and
2. the time it takes to run the code

I've seen a lot of focus on the first of those points with ideas like using static checkers (including SAST applications). While it is true that this will reduce the carbon associated with creating the code, it ignores what in most cases is a significant additional step. How much carbon does it take to run the code? Unless the code is only used a few times (like a batch process) and is not used by a legion of users, the chances are that all the execution runs are going to add up to a lot of use. So reducing the time it takes to execute is going to be important.

So to the topic of less code vs faster code. There has to be an understanding of ideas like short circuiting a calculation or storing interim values to make either that calculation faster or subsequent calculations faster. Also we are not talking about making the code so complex that it is very hard to understand, but really, good commenting can help there. We are talking about the balance between 'creating and maintaining the code' vs 'running the code'. As a starter, I'd like to suggest reading the following and while it focusses on JavaScript, the principles apply to most languages and approaches to solutions: https://javascript.plainenglish.io/is-elegant-javascript-always-performant-concise-vs-fast-code-explained-da90b766f13b

This does fall into the category of DS&A (Data Structures and Algorithms) and certainly creating code can be complex enough as it is, but we're having this conversation because we know that every little bit counts and so we need to push this conversation forward. I'm hoping I've not missed a thread where this is already being discussed and if it is not, then lets get the conversation going.

As for how to practice, I personally think that coding challenges are great for that and at this time of year what better challenge to go for than the Advent of Code. This year my youngest has said he wants to give it a try as he is off to University next year and as it happens he has chosen Python as the language he wants to use, so I guess I'm learning Python. But really if last years challenge is anything to go by, we are going to have to really think about the efficiencies of what we create.

So what's next, can we create a list of criteria/thoughts that a developer should go through? Or do you have another idea?

[NAMRATA-WOKE]

@russelltrow

[mistrc]

I thought I would give an update on where things are with this. Firstly as luck would have it the YouTube channel Computerphile did an episode on Optimising Code, which brought up a few points that I had not thought of on this topic, the main one being about one way to optimise code is to optimise the code so that it would ensure that the CPU would use less power when doing the calculation. That is a wonderful idea in itself, but as they caution, you would need to know details of your specific use case, in this case, the CPU that you are running on. Additionally you would have to be using a language that allowed you to have control to tune how the code is executed. All this can get quite into the weeds on the topic and shows that there are many branches for the conversation to go along.

But this itself talks to the benefit of working on this pattern in a group, so that we can cover as much as possible and more clearly specify what we want to focus on first and what will come later. As for working on this, (i) I've looked further into the information available here, and I do believe that there is space for a pattern to be created on this topic, also (ii) the following is a link to the Patterns section that describes how to submit a pattern for review and specifies that "Anyone can submit a pattern". So next I'll start to work on filling in the required information and if you'd like to help, even on a small part of the thought process, please do reach out.

For reference, as I see it there is detail to this. There is the wisdom that I was taught be a tech lead on a project that I worked on early in my career about optimising code, which was that the first rule of optimisation is to not do it and to actually wait, and the second the the third rules said the same thing. The point being that you can't optimise the code until you see it being used and capture metrics from its execution. That said there is the base expectation that what has been implemented has been architected well because people are conversant in data structures and relative performance of different patterns of solutions (i.e. Big O Notation). So as I see it, those are the two parts (data structure complexity and optimising via profiling) that we can focus on for now. That leaves other topics like optimising for a CPU or language specific optimisations, for now, out of scope. Of course, I'm happy to discuss further if you feel there is a better angle to attack this from, but as I say, please do reach out if you'd like to get involved

[StSchnell]

Excellent considerations @mistrc,