Performance of applications I write was always something I deeply cared about. I’m talking about using as few resources as possible, but of course not in the detriment of other important things. Teams often neglect this and take action only when there is a perceivable performance issue.

When is the right time to optimize?

I would say it always need to be on your mind, but before you wrap up the project it is always good to tighten the screws and optimize what you can.

Decisions around your data model will have a big impact on performance and it is very hard to change at the end phase of a project. This is the reason why I say, you need to be mindful about performance all the time.

In the last sprints of the project, most of the important flows are already there. You understand the application a lot better then you did in the beginning. Since everything is there this period is a good opportunity to poke around and see how some important flows perform. Also you are in a better position to form and educated opinion whether something needs improvement or not.

Should I optimize everything I can?

No! The biggest mistake I see people do is to change something they know can be optimized, without measuring the impact it can bring. Here is where profiling comes in. Since your time is limited it is important to concentrate effort in places where it brings the most value.

Often clients need to be convinced to give you time. This is a lot easier when you can demonstrate to them that there is an issue. I usually ask them to give me a few days to conduct analysis after which I assemble a report like document where I highlight some important facts and make some conclusions on what actions need to be taken. If you do this right you can have their instant buy-in and they will have something with which then can also go to their stakeholders. Plus you look professional AF.

Ok how should I do this?

Pick a few scenarios that are important to you and break it into steps. Measure the time it takes for each step and analyze the results. People often concentrate too much on finding a good tool, but my opinion is that you can already do a decent job if you do things manually.

The easiest way to do profiling is to place logs in your code (Trace level is good). Make sure do the following:

1. Compile the code with code optimizations (Release mode) because you don’t want to spend time optimizing something that your compiler will do for you.
2. Run the application without an attached debugger because it will introduce delays and you don’t want to be sidetracked by false positives.
3. Reduce variance as much as you can. Between executions it is expected to get slightly different result so it is a good idea to free up the computer of any other activities that could slow down your system (no YouTube).
4. Collect your results in an analyzable way (Excel would be a good choice).

How to pick what to improve?

I make the distinction between the following levels of changes.

1. Local: The change calculation, individual steps in a flow (algorithm changes, parallelization, memory allocation, etc.).
2. Data structure: You make the decision to optimize the data structure used (field type changes, merging tables, improving query performance, etc.)
3. Data access: These leave the data structure intact, but changes on how often you read/write something (Caches, Lazy Loading, Indexes, Pre-calculations, etc.)
4. System: These change how systems work together (Exchange data formats, API consolidation, scaling parameters)

It is always a good idea to prioritize in this order. For example in a cloud environment you always have the option to increase the hardware dedicated to your processes, but doing that before Local, Data structure changes might result in money thrown out the window unnecessarily. Additionally to these I try to map any improvement idea into the following way.

Green is the low hanging fruit area, you need to start with these. You continue with yellow is a bit more work but it still improves the system greatly. If you still have time you continue with orange. Red you probably are never end up doing. It’s not worth it.

I hope this was helpful and later we will delve into some more concrete examples. Until check out the improvements on the poker hand evaluator here. See ya!