Optimal code?

    For several years now I have been working on one very interesting device. During this time, from 40 calculated indicators, the system grew to about 300, and my views on the “correct” code changed a lot.

    At the very beginning of the work, there was a desire to optimize the speed of calculating indicators as much as possible, I used “tricky” algorithms for caching values ​​of calculated indicators, which will be further used to calculate other values. I looked, and was glad how “cool” I thought and designed everything.

    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, gradually the speed was exchanged for computationally clear algorithms. When the number of input indicators increased from 30 to 80, and the calculated ones to 300, the code was already very far from the optimal in speed. The calculated indicators referred to others, others to third, and so several levels of nesting, at each of which the same values ​​were repeated.

    On the one hand, it is a nightmare - so many vain calculations, a vast 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. Under the same financial constraints, the power of iron has grown so much that non-optimized algorithms on new hardware work faster than optimized ones on old.
    3. The indicators are calculated discretely, the CPU load at the time of calculation increases by no more than 3-4% with a total constant load of 20-25 and a peak load of 50%
    4. Periodically, the relationships between the indicators change, you have to understand what has been done earlier, to make changes and additions
    5. The most valuable thing - when you look at the calculation function of any indicator, it is clear what is meant.

    Conclusion: the criteria for optimizing the code and algorithm depend on each specific task, and now they are more and more shifting from optimization for iron to optimization for a human developer, as the situation allows. The pieces of iron are getting steeper and cooler every day, and programmers are getting older and older :)

    Also popular now: