Browsing Russian translation

1.

The Quick Guide to Optimizing GNOME Programs

2.

This is a brief introduction to optimization, both the hows and the whys. Details of individual tools and techniques are left for later articles, but a collection of hints and tricks is provided.

3.

What are we Optimizing?

4.

When we optimize for GNOME the first thing to remember is this: we are not trying to make the program better, we are trying to make the person using the computer happier.

5.

Better programs make people happier, but there are some improvements that will make them a lot happier than others: Responsiveness, start-up time, easy to access commands and not having the computer go into swap the moment more than two programs are open.

6.

Traditional optimization tackles concepts like CPU use, code size, the number of mouse clicks and the memory use of the program. This second list has been chosen to correlate with the first list, however there is an important difference: The person using GNOME doesn't care about the second list, but they care a lot about the first list. When optimizing GNOME programs we will reduce CPU use, memory use and all those things, but these are the means to the end, not the final goal. We are optimizing for people.

7.

Doing the Optimization

8.

The previous section omitted one important qualifier: To optimize something it has to be measurable. You can't measure happiness. However, you can measure start-up time so you can tell if you have improved it. Happiness will then, hopefully, follow.

9.

Optimization is the process of measurement, refinement and re-measurement. So the first thing you must do is find a way to measure what you are optimizing. Ideally this measurement is a single number, for example: the time taken to perform a task. This is your benchmark, it is the only way to tell if you are winning or losing. There is a big difference between a program that <emphasis>should</emphasis> be fast and a program that <emphasis>is</emphasis> fast.

10.

Once you have a basic benchmark you need to find out why your code is not doing as well as it should. It is tempting to do this by inspection: just looking at the code and trying to spot something that looks like it needs improvement. You will invariably be wrong. Using a profiler to get a detailed break-down of what your program really does is the only way to be sure.