Вашему вниманию предлагается перевод статьи Дениса Форбса (Dennis Forbes) "The Sad Reality of Post-Mature Optimization". Превосходные иллюстрации также взяты из оригинальной статьи.
Знаменитое утверждение «преждевременная оптимизация — корень всех зол» принадлежит перу Дональда Кнута. К сожалению, изначальный смысл этой фразы давно утерян, и в последнее время её используют лишь как отговорку, позволяющую отбиться от любых претензий к скорости работы программы.
На каком этапе разработки пора обратить внимание на производительность? В какой момент оптимизация перестает быть преждевременной и становится своевременной?
Распространенное мнение таково: заботьтесь о производительности только тогда, когда вы уже написали большую часть кода. Казалось бы, всё очень просто: запускаем профилировщик, находим все проблемные места в коде и оптимизируем их. При таком подходе результат (вроде бы!) должен быть таким же, как если бы вы думали о производительности с самого начала. Знакомые слова, правда?
Проработав в индустрии не один год и завершив не один десяток проектов, могу с уверенностью заявить: это полная чепуха. На самом деле всё происходит совсем по-другому.
Вот что должен показать профилировщик, если запустить его на идеальной, гипотетической программе, которая с самого начала писалась с учетом высоких требований к производительности. Все методы в ней выполняются одинаково быстро, и мест, где бы просаживалась производительность, просто нет.
Когда вы натравливаете профилировщик на проект, написанный под лозунгом «скажем "нет" преждевременной оптимизации!», вы ожидаете увидеть что-то в этом духе.
На практике такого не случится никогда. Ни-ког-да. Если вы не ставили производительность во главу угла с самого начала, то неэффективные решения будут появляться повсюду, заражая каждый квадратный килобайт кода в вашем проекте. Зачем использовать хэш-таблицы, когда можно втупую итерировать по громадному массиву? Зачем писать SQL-запросы, когда можно использовать LINQ на каждый чих, постоянно отфильтровывая огромный объем избыточных данных?
В большинстве случаев профилировщик нарисует вам вот что:
Эта ситуация абсолютно типична. Если вы не задумались о производительности с первых дней проекта — поверьте, вы не вспомните о ней до самого конца. Не надо тешить себя надеждами типа «мы найдем самую неэффективную функцию, быстренько ее оптимизируем, и всё сразу заработает быстрее!». При таком подходе зараженными окажутся все функции, и точечное лечение вам не поможет. Закон Мура тоже не придет вам на помощь: производительность отдельно взятого процессорного ядра практически не меняется вот уже несколько лет. Девять женщин никогда не смогут родить ребенка за один месяц; так и в вашем случае мечты о том, что рано или поздно хорошее железо позволит вашей программе работать быстро, разобьются о физические ограничения.
Хотите примеров из жизни? Пожалуйста. Минимальное время рендеринга одной страницы бизнес-портала SugarCRM — в районе 100 миллисекунд, даже на самом лучшем железе. В мире веб-приложенй такое положение дел никого особо не смущает (все уже давно привыкли к тому, что каждый клик на веб-странице обрабатывается по несколько секунд), но ситуация дошла до того, что малое время отклика стало для некоторых веб-сервисов серьезным конкурентным преимуществом. Мне очень нравится интернет-радио Rdio, но если я найду его аналог, который не будет доставать меня секундными задержками между переключениями страниц, то я немедленно перейду на него.
У вас редко получается пофиксать все баги перед релизом; точно так же у вас не получится решить все проблемы с производительностью в короткие сроки. Ситуация очень схожа с попыткой распараллелить алгоритм, который изначально не был для этого предназначен: в принципе, это возможно, но скорее всего потребуется переписать всё с нуля.
Подытожу вышесказанное: полезный принцип, высказанный Кнутом, был доведен до полного абсурда. Когда кто-то говорит о преждевременной оптимизации, он почти наверняка имеет в виду совсем не то, что имел в виду Кнут.
Знаменитое утверждение «преждевременная оптимизация — корень всех зол» принадлежит перу Дональда Кнута. К сожалению, изначальный смысл этой фразы давно утерян, и в последнее время её используют лишь как отговорку, позволяющую отбиться от любых претензий к скорости работы программы.
На каком этапе разработки пора обратить внимание на производительность? В какой момент оптимизация перестает быть преждевременной и становится своевременной?
Распространенное мнение таково: заботьтесь о производительности только тогда, когда вы уже написали большую часть кода. Казалось бы, всё очень просто: запускаем профилировщик, находим все проблемные места в коде и оптимизируем их. При таком подходе результат (вроде бы!) должен быть таким же, как если бы вы думали о производительности с самого начала. Знакомые слова, правда?
Проработав в индустрии не один год и завершив не один десяток проектов, могу с уверенностью заявить: это полная чепуха. На самом деле всё происходит совсем по-другому.
Вот что должен показать профилировщик, если запустить его на идеальной, гипотетической программе, которая с самого начала писалась с учетом высоких требований к производительности. Все методы в ней выполняются одинаково быстро, и мест, где бы просаживалась производительность, просто нет.
Когда вы натравливаете профилировщик на проект, написанный под лозунгом «скажем "нет" преждевременной оптимизации!», вы ожидаете увидеть что-то в этом духе.
На практике такого не случится никогда. Ни-ког-да. Если вы не ставили производительность во главу угла с самого начала, то неэффективные решения будут появляться повсюду, заражая каждый квадратный килобайт кода в вашем проекте. Зачем использовать хэш-таблицы, когда можно втупую итерировать по громадному массиву? Зачем писать SQL-запросы, когда можно использовать LINQ на каждый чих, постоянно отфильтровывая огромный объем избыточных данных?
В большинстве случаев профилировщик нарисует вам вот что:
Эта ситуация абсолютно типична. Если вы не задумались о производительности с первых дней проекта — поверьте, вы не вспомните о ней до самого конца. Не надо тешить себя надеждами типа «мы найдем самую неэффективную функцию, быстренько ее оптимизируем, и всё сразу заработает быстрее!». При таком подходе зараженными окажутся все функции, и точечное лечение вам не поможет. Закон Мура тоже не придет вам на помощь: производительность отдельно взятого процессорного ядра практически не меняется вот уже несколько лет. Девять женщин никогда не смогут родить ребенка за один месяц; так и в вашем случае мечты о том, что рано или поздно хорошее железо позволит вашей программе работать быстро, разобьются о физические ограничения.
Хотите примеров из жизни? Пожалуйста. Минимальное время рендеринга одной страницы бизнес-портала SugarCRM — в районе 100 миллисекунд, даже на самом лучшем железе. В мире веб-приложенй такое положение дел никого особо не смущает (все уже давно привыкли к тому, что каждый клик на веб-странице обрабатывается по несколько секунд), но ситуация дошла до того, что малое время отклика стало для некоторых веб-сервисов серьезным конкурентным преимуществом. Мне очень нравится интернет-радио Rdio, но если я найду его аналог, который не будет доставать меня секундными задержками между переключениями страниц, то я немедленно перейду на него.
У вас редко получается пофиксать все баги перед релизом; точно так же у вас не получится решить все проблемы с производительностью в короткие сроки. Ситуация очень схожа с попыткой распараллелить алгоритм, который изначально не был для этого предназначен: в принципе, это возможно, но скорее всего потребуется переписать всё с нуля.
Подытожу вышесказанное: полезный принцип, высказанный Кнутом, был доведен до полного абсурда. Когда кто-то говорит о преждевременной оптимизации, он почти наверняка имеет в виду совсем не то, что имел в виду Кнут.
