Since this is a first post in this blog, I decided to start with some more ‘lighter’ (or philosophical) topic. I will try to abstract this from code development, as this kind of discussion can be easily held for any type of project or activity.

In my work I often hear phrases similar to: ‘With these changes we have gained X% of performance’. ‘Good job!’ would be an answer most people would dream off. Instead, experienced audience comes to sentences like this with a dose of healthy distance. The statement is usually followed by a series of supportive questions:

• ‘What is the reference you used to evaluate this gain?’,
• ‘What is the maximum performance we could get?’,
• ‘Have you tried comparing this results with XYZ?’,
• ‘What are you measuring?’,
• ‘So what?’ etc.

If the discussion continues, then the number of questions can grow further ad infinitum. But are these questions valid and do they have valid answers? Can we answer them right away and is it even practical to answer them? Is this information useful to the people who are listening? Let’s try analysing the real reason why these questions are being asked.

So what?

Let’s first start with the last question. In order to answer this question you have to ask some more questions:

• External impact: Will this performance gain impact my customers/users’ experience in any way?
• Internal impact: Can this modification be reflected in other places in the project/company/community to gain performance there?
• Local impact: Will this modification impact our future project evolution (e.g. code development)?

As you probably noticed, it is all about impact. If you have to spend six months trying to increase performance, and nobody will notice this change, then you effectively wasted that time. On the contrary, if you can positively impact your customers, then it might be worth doing. Knowing what are the expectations of external customers will help you to better asses the significance of a specific optimization.

The optimizations that have internal impact can be useful only if they can be practically transferred to other projects in the close vicinity of what you are doing (e.g. inside your company/organization or within the community).

Doing optimizations that have local impact is worth the effort only if they accelerate the work that you and your colleagues are doing.

Donald Knuth coined a very popular quotation phrase:

Premature optimization is the root of all evil.

While this phrase seems to be overused lately to justify incompetence and/or laziness, one thing is sure:

Do not start optimizing unless you know what kind of impact it brings.

What are you measuring?

A branch of science called metrology has been developed around this question. And this science is a fundamental prerequisite for any optimization. There are two aspects of this science that you should consider when starting your optimization process.

At the core of optimization process is something called ‘an objective function’. Few examples of different optimization problems and objective functions are:

• A stock market investor wants to maximize amount of money gained.
• An Olympic runner wants to minimize the time it takes him to run 100 meters distance.
• An ecology activist wants to minimize environmental impact of industry.

First of all you need to know what is your objective function and what is the unit you will be measuring. In the first example the amount of dollars is a fair unit of profit. The same amount expressed in euro would be acceptable as well, as it is straightforward to convert this unit into dollars and back. In the second example we would probably use seconds as a unit of choice, but we might as well use miles per hour.

The choice of a metric for the last example would be a very complex task. First of all, a good metrics would have to be easily quantified. If we cannot quantify, we usually cannot compare. How then would we quantify the environmental impact? By the number of cancer deaths caused by nuclear waste? By the amount of CO2 in the atmosphere? By the number of species extinct per year? Or maybe we do a weighted sum of all of these quantities?

This brings us to the second aspect of the proper measurements: the methodology of measurement and results comparability. Comparison between profit of two stock brokers residing in New York (‘dollars’ as unit) is trivial. Similar comparison between one residing in New York, and another one in London (unit is ‘pounds’) can be done if we know current exchange rates. Because the exchange rates change every second, we might find out that due to some financial crisis, suddenly our leading American stock broker is not worth a penny in UK. For the second example, it would be reasonable to do comparison between two runners participating in the same contest. Trying to compare handicap runner with a healthy one is considered to be an unfair comparison. Trying to compare a runner with a F1 car would be considered a nonsense.

In the last example we cannot even translate the concept of CO2 into number of species extinct in last century. While we could possibly find some correlation between the two, the number of data samples for the extinctions wouldn’t be meaningful in statistical sense. And of course we cannot (for both practical and moral reasons) repeat the extinction events.

Be careful about metrics and measurements.

Have you tried comparing this results with XYZ?

Another cliche saying is: Do not compare apples with pears. . Of course you can compare apples and pears if you choose proper feature that is common to both of them.

To have a valid comparison we need to have a proper experimental setting. To design a proper comparison experiment, we need to have a deep understanding of what we are trying to compare and for what reason. Say that you already have a setting that compares apples of different sort, one that measures: the radius of an apple, saturation of red and/or green skin color or the amount of sugar that can be extracted from the apple. Your best customer comes one day and says: ‘Well, we’ve been selling best apples for past ten years, and we are really happy from the data you’ve been giving us. We would like to broaden our market and start selling pears. Would you be so kind to give us the same data about different variety of those?’.
Now this gets you thinking… As an expert in the apple optimization, you can say: ‘Well it doesn’t make sense to measure radius of a pear, as it is not a spherical shape. We would have to develop a mathematical model of the pear curvature and then compare that. The pears are also rarely red, but we could adjust the saturation check for yellow and/or green. Extracting the sugar would probably stay the same?’. The excited customer says then: ‘Great! Can you also produce some type of comparison with the apples we’ve been selling so far?’.

Now that last sentence is really confusing…

In our little example the only feature we can compare without much doubt is the amount of sugar content. We could also compare green (or maybe even yellow) skin saturation for both types of fruit, but once we get a truly yellow pear, and a truly red apple, this comparison stops having any sense. What can you do in this case? Well you have to start developing a new experiment. You have to pick different qualities to compare, such as: acidic contents, pulp hardness, juiciness etc. If you however keep treating the radius as a metric, then the question that somebody will eventually ask you would be: ‘But how are you measuring the radius of a pear?’.

This kind of question is commonly asked in scientific community, and is very cleverly evaded by sales officers in the industry. You have to be really careful about what you are comparing and what experimental setting you are using.

What is the maximum performance we could get?

This is a really common question, a really interesting one, a really tricky to answer with one sentence, and in most cases an irrelevant one.

In rare cases the optimal solution is already known, and we could use it as a baseline. More often, we don’t know the best possible solution, but we know the state-of-the-art. Lastly, we might have no clue whatsoever about possible top performance.

If we are in the first category, it is pretty straightforward to asses the impact of further optimizations. If we are in the second group, then we can at least say that we can get better than the best-known solution. When we are in the last group – the whole science unravels.

A popular method of evaluation of potential performance is to create a mathematical model of an ideal solution, and perform a simulation. This is a tedious and expensive process. Think of the Olympic runners: how complex the model of a human body should be to give us results accurate up to 100’th of a second? And we could always develop even more precise model for this kind of evaluation.

For majority of practical engineering it is probably unnecessary to know this evaluation. Why? Well, the debate would go back to Knuth saying that we should focus on the optimizations having biggest impact, and try improving that one first. In other cases (e.g. Ultra High Frequency Trading) you are only interested in having a solution that works a fraction of the second faster than anybody else. So getting 0.001% faster than your competitors is enough to solve all your problems.

There is only one reason that I think makes knowing what is ‘the maximum performance’ valuable: letting go and moving on. If you know the maximum that you can get, and you know you are very close to that value, you can move to another optimization problem. There is a rule in economics called ‘a law of diminishing returns’ which states:

The return on investment decreases as you increase investments in only one factor, and keep other factors constant.

In other words: if you cannot further optimize in local context, you have to start optimizing in a broader sense. If you think about problem of minimizing fuel consumption in air planes, the optimizations might be already so advanced, that the only viable solution is to do full re-design of the machines.

Estimating maximum performance can be difficult and expensive. Using the same resources for optimization can be more useful.

What is the reference you used to evaluate this gain?

A reference value, is some value that we use to compare with. For a given experiment we can say that we have improved if the new result is better than the reference result. If the result is worse than reference, then we would observe performance degradation . Now depending on what reference we select, we can observe improvement of hundreds of percent, decrease of hundreds of percent or no difference at all! Now, this is a playground for marketing department!

I am of the opinion that it is the most important to select one reference point at the beginning of the optimization process, and stick with it for the rest of the project. A common mistake is to show improvement over the previous iteration of the optimization process. This leads to performance gains jumping around over the time, misleading result presentations and makes overall post-optimization analysis more difficult.

An example: say you start preparing for 100m run. Your first result in the optimization process (or ‘training’) is 100 seconds. It is not even near the Olympic record, but it doesn’t matter at this moment. The result you get will allow you to track your future progress. Next you decide, you will be training for a six months period, and do the timing results every month. So you get following values (mind there are 7 results, but only 6 months):

100, 40, 30, 25, 33, 22, 20

You can now calculate the improvements against the previous iterations:

-, 250%, 33%, 20%, -24%, 50%, 10%

As you can see it is difficult to say what happened, and if you don’t explain your audience that the negative value (e.g. caused by an injury) is actually a very good result, people might get confused. Also the 50% improvement after that incident would also look misleading.

If you use the initial reference for every ‘performance gain’ then you will get following:

-, 250%, 333%, 400%, 303%, 454%, 500%

Now that is much easier to read. Turns out that the 10% of the last improvement was actual 500% improvement in regard to reference. You also get the information, that the ‘10%’ from previous representation, is actually 5x improvement over your initial result. I don’t know about you, but for me this representation looks more satisfying, and easier to work with. You could even apply some inverse polynomial regression to figure out, that in next 6 months you could get to 13s timings! I agree – this is not a very realistic example, but still proves the point.

People are often using the first notation instead of the second one. And the reason is simple: no systematic performance evaluation over the project evolution. It is much easier to just take current code repository snapshot, do the measurements, make some optimization changes, and run measurements again. It is compelling, because otherwise the optimization process would have to be carried back over the past (and ancient) versions of the project. And people usually don’t want to waste time on doing so.

Carry on measurements from the beginning of your optimization process. Always use the same reference.

What is ‘Performance’?

I would try defining performance as a quality represented by a quantitative value, measured in some experimental setting, and used to compare different solutions of the same problem.

Now this sounds more scientific than I intended, but I guess it is necessary to establish some common language so that I could use the word ‘performance‘ in future posts without being exposed to linguistic struggles.

Performance makes only sense when it is used for comparison. There is no reason to talk about performance when your project doesn’t solve actual problem. And there should be no misconception that decreasing performance is a bad thing. You can add a feature to your project and suddenly you have different evaluation setting available. Even if you degrade with the measured values now, you are also solving a different problem! In that sense you should start the optimization process from the beginning, discarding the old reference.

About this blog

Anyways, this entry is already too long for a blog post, so it is time to close it now.

The topics I will be exploring in this blog, will usually relate to the questions that were discussed above. Because this is intended to be a software engineering blog, I will be trying to provide you with some practical tips on how to perform this kind of evaluation in context of the software.
However, since the performance is a general topic, I will also try presenting different techniques, such as statistical tools, which can also be applied in other domains.

It’s time to gain performance (and some feedback).

Cheers,
Przemek.