В самом начале работы было желание максимально оптимизировать скорость вычисления показателей, я использовал "хитрые" алгоритмы кеширования значений расчетных показателей, которые будут в дальнейшем использоваться для вычисления других значений. Смотрел, и радовался, как же "круто" я все продумал и сделал.

Но со временем уточнялась теория и возникала необходимость изменять не только нормы, коэффициенты и формулы вычисления показателей, но и алгоритмы получения значений вообще. В итоге постепенно скорость разменивалась на понятные глазу алгоритмы вычислений. Когда же количество входных показателей выросло с 30 до 80, а расчетных до 300, код уже был очень далек о оптимального по скорости. Вычисляемые показатели ссылались на другие, другие — на третьи, и так несколько уровней вложенности, на каждом из которых повторно производились вычисления одних и тех же значений.

С одной стороны, это кошмарно — столько напрасных вычислений, необъятное поле для оптимизации. Но если взглянуть на проблему шире, ситуация меняется в корне:
1. Программа используется на предоставляемом разработчиком железе
2. При тех же финансовых ограничениях, мощность железа выросла настолько, что неоптимизированные алгоритмы на новом железе работаю быстрее оптимизированных на старом.
3. Показатели вычисляются дискретно, нагрузка на ЦП в момент вычислений увеличивается не более чем 3-4% при общей постоянной нагрузке в 20-25 и пиковой в 50%
4. Периодически, взаимосвязи между показателями изменяются, приходится разбираться в том, что было сделано ранее, вносить изменения и дополнения
5. Самое ценное — при взгляде на функцию вычисления любого показателя понятно, что имеется ввиду.

Вывод: критерии оптимальности кода и алгоритма зависят от каждой конкретной задачи, и сейчас они все больше и больше смещаются от оптимизации под железо к оптимизации под человека-разработчика, насколько позволяет ситуация. Железки с каждым днем становятся вcе круче и круче, а программисты — все старее и старее :)