Timely optimization

Everyone knows that premature optimization is bad and you have to pull yourself when you want to optimize at the wrong time. However, in practice, more often there is a situation when the natural (and, possibly, intuitively correct) desire to optimize is suppressed according to the principle “if not optimized at all, this will not be premature.” Either way:



In my opinion, such situations arise because the concept of “prematureness” is very vague and intuitive, as if it is something empirical and elusive, like the crispness of the crunch of a French loaf.
')
Although in principle it is rather strange to operate with some empirical concepts in relation to the architecture of programs, algorithms and their optimization - since these are quite measurable things. And that means - you can simply measure the timeliness of optimization. About this and talk.

What is optimization?

Optimization in simple terms is bringing the program from the “not happy” state to the “happy” state in terms of performance parameters (runtime, resource consumption, throughput). Those. we know which indicators suit us, and when we see that the program does not hold out to them - it's time to optimize it.

What is premature optimization?

In those cases when we think that we are in a state of “not satisfied”, but in fact everything “suits” we optimize prematurely.

What is timely optimization?

We know that the program is already / just about to be / will “not suit” - and we take measures to remedy the situation.

In an ideal world, we create a program that meets the requirements, we release it at will - and there we are all “satisfied” at once. As happens in the real world more often, we all know perfectly well.

Fortunately, in order to understand whether we are optimizing timely or prematurely, you need to perform the same actions and for this usually a sheet of paper is enough.

Measurable timeliness

In general, the measure of timeliness / prematurity in itself requires fairly simple actions:

1. Take performance requirements
2. Calculate whether the program fits into these requirements.
3. If it fits - live happily; otherwise - optimize the program

Since the most common requirement is response time, bandwidth comes down to it, and resource consumption is a separate and large topic focusing on the first.

So, we have the required program execution time - TV and the required number of data processed per pass - TD.

We are still just designing or developing a program, and the feeling that something is not going optimally and a fear of premature optimization does not leave us. To measure our sensation and prevent the development of phobias, follow these steps:

1. Determine the time complexity of the designed / developed algorithm O (n), taking into account the constants. 3 * n so 3 * n, n * logn + n, etc. The more accurate, the better.
2. Get the number of operations performed per pass - KO by substituting TD in a function that describes the time complexity.
3. Calculate the average allowable processing time for a single element - the BEL of the input array (we mean a high-level entity, one document, one user) based on TB. Those.
   BOO = TB / KO
   
4. Next, we make sure that the actual processing time of a single element <= the average allowable processing time of a single element , if necessary, repeating steps 1 and 2 for programs / algorithms that are higher in the stack.

Let's look at a simple example.

Suppose that we need to write a program that must process 100 records and fit in 2 seconds. In the course of development, we came up with a certain algorithm whose temporal complexity is O (n ^ 2).

In this case, we have 2/100 ^ 2 = 2 * 10 ^ -4 seconds (0.2 milliseconds or 200 microseconds) on average to process each record. This is enough to perform simple actions (arithmetic and memory accesses take tens or hundreds of nanoseconds, if, for example, judged by this infographic ), but any kind of network interactions are no longer available.

Those. if we write a sort of an array of numbers for such requirements, we are “satisfied”, and if we need to send 100 SOAP requests, we are “not satisfied” and it is time to think of something.

Conclusion

In general, this is all, this approach is easily scalable and makes it easy to estimate the upper limit of timeliness, eliminates a sense of uncertainty and increases the meaningfulness of the programs produced. And most importantly - it makes your users and managers happy, because in production less is on.

Naturally, this approach is not enough for putting into commercial operation - therefore, consult with a specialist before refusing load tests.

Thanks for attention!