The optimal code?
For several years now I have been working on one very interesting device. During this time, out of 40 calculated indicators, the system has grown to about 300, and my views on the "correct" code have changed a lot.
At the very beginning of work, there was a desire to optimize the speed of calculating indicators as much as possible; I used “clever” algorithms for caching values ​​of calculated indicators, which will later be used to calculate other values. I watched and was happy how “cool” I thought of everything and did.
But over time, the theory was refined and there was a need to change not only the norms, coefficients and formulas for calculating indicators, but also algorithms for obtaining values ​​in general. As a result, the speed was gradually exchanged for clear-looking computing algorithms. When the number of input indicators increased from 30 to 80, and calculated to 300, the code was already very far from optimal in speed. The calculated indicators referred to others, others to third, and so several levels of nesting, on each of which the same values ​​were repeated.
')
On the one hand, this is nightmarish - so much useless computation, an immense field for optimization. But if you look at the problem more broadly, the situation changes radically:
1. The program is used on the hardware provided by the developer.
2. With the same financial constraints, the power of iron has grown so much that non-optimized algorithms on new hardware work faster than those optimized on the old one.
3. Indicators are calculated discretely, the load on the CPU at the time of the calculations increases by no more than 3-4% with a total constant load of 20-25 and a peak of 50%
4. Periodically, the relationship between the indicators change, you have to understand what was done earlier, make changes and additions
5. The most valuable thing - when looking at the function of calculating any indicator, it is clear what is meant.
Conclusion: the criteria for optimality of the code and algorithm depend on each specific task, and now they are increasingly shifting from optimizing for hardware to optimizing for a human developer, as far as the situation permits. Every day the pieces of iron are getting steeper and steeper, and programmers are getting older and older :)
At the very beginning of work, there was a desire to optimize the speed of calculating indicators as much as possible; I used “clever” algorithms for caching values ​​of calculated indicators, which will later be used to calculate other values. I watched and was happy how “cool” I thought of everything and did.
But over time, the theory was refined and there was a need to change not only the norms, coefficients and formulas for calculating indicators, but also algorithms for obtaining values ​​in general. As a result, the speed was gradually exchanged for clear-looking computing algorithms. When the number of input indicators increased from 30 to 80, and calculated to 300, the code was already very far from optimal in speed. The calculated indicators referred to others, others to third, and so several levels of nesting, on each of which the same values ​​were repeated.
')
On the one hand, this is nightmarish - so much useless computation, an immense field for optimization. But if you look at the problem more broadly, the situation changes radically:
1. The program is used on the hardware provided by the developer.
2. With the same financial constraints, the power of iron has grown so much that non-optimized algorithms on new hardware work faster than those optimized on the old one.
3. Indicators are calculated discretely, the load on the CPU at the time of the calculations increases by no more than 3-4% with a total constant load of 20-25 and a peak of 50%
4. Periodically, the relationship between the indicators change, you have to understand what was done earlier, make changes and additions
5. The most valuable thing - when looking at the function of calculating any indicator, it is clear what is meant.
Conclusion: the criteria for optimality of the code and algorithm depend on each specific task, and now they are increasingly shifting from optimizing for hardware to optimizing for a human developer, as far as the situation permits. Every day the pieces of iron are getting steeper and steeper, and programmers are getting older and older :)
Source: https://habr.com/ru/post/30289/
All Articles