Мне кажется, в этих рассуждениях упущен один важный момент: когда вы начнёте оптимизировать программу, может случиться так, что вы не найдёте очевидных мест просадки производительности (или после оптимизации программа будет всё равно работать медленно). Просто неэффективный код будет размазан по всему проекту.
Допустим, рендеринг страницы состоит из последовательного вызова 30 функций. Тогда общее время рендеринга будет равно (t1 + Δt1) + (t2 + Δt2) + ...
Так что же делать? Однозначного ответа на этот вопрос нет. Я стараюсь поступать следующим образом. При написании программы я оптимизирую код, если:
- переписанный код не потеряет в надёжности, безопасности и читаемости по сравнению с оригинальным неоптизированным кодом,
- переписывание кода не займёт у меня слишком много времени,
- я точно уверен, что переписывание действительно улучшит быстродействие приложения.
Или, например, HashMap<Integer, Integer> я заменяю на TIntIntMap из trove4j. В этом случае безопасность даже повышается, т.к. у TIntIntMap сигнатуры более строгие, чем у Map, и не позволяют, к примеру, написать map.containsKey("abc").
Самое трудное – это выполнить третий пункт. Дело в том, что очень часто трудно понять, имеет ли вообще смысл оптимизация, ведь современные компиляторы сложны и непредсказуемы. И поэтому в кодах программ встречается огромное количество бессмысленных оптимизаций, в результате чего в среде программистов и сложилось мнение, что вообще все преждевременные оптимизации – зло. Но ведь не все оптимизации бессмысленны, верно?
Комментариев нет:
Отправить комментарий