Мы переходим к основной
теме нашего курса «Красный пояс по C++» — это создание быстрого и эффективного кода.
C++ так популярен именно из-за того, что позволяет писать быстрый
и эффективный код и выжимать максимум из ваших вычислительных мощностей.
Но, естественно, не любой код, написанный на C++, является по умолчанию быстрым.
При неумелом использовании возможностей языка можно получить код, который
будет работать очень медленно, независимо от того, на каком языке он написан.
До этого мы с вами только вскользь касались темы эффективности
и скорости работы тех или иных конструкций языка.
Теперь же давайте детально поговорим о том, как на C++ писать быстрый код.
И начнем мы вот с какого вопроса: а что же такое быстрый код?
Вот, допустим, у меня есть какая-то программа,
которая запускается в течение пяти секунд.
Это быстро или нет?
Естественно, ответ на этот вопрос зависит от того,
какую задачу решает эта программа.
Ну, например, я каждый день, приходя на работу,
запускаю на своем компьютере IDE и работаю в ней целый день.
Если эта IDE запускается пять секунд, то, я думаю, это достаточно быстро,
потому что потом она работает несколько часов подряд до конца рабочего дня.
Но если же пять секунд занимает запуск мобильного приложения,
то это, конечно, очень медленно,
потому что многие люди одно и то же приложение запускают несколько раз в день,
например какой-то мессенджер или вашу любимую социальную сеть,
и если каждый запуск занимает пять секунд или больше,
то это очень медленно и это сильно портит опыт использования.
И отсюда у нас появляется первая
важная мысль: код не бывает просто быстрым или медленным.
Он не бывает быстрым или медленным в вакууме.
Он бывает либо достаточно,
либо не достаточно быстрым для той задачи, которую он решает.
И эта мысль нас приводит к первому правилу
оптимизации кода: избегайте преждевременной оптимизации.
Что такое преждевременная оптимизация?
Это когда мы при разработке программы во главу угла ставим скорость работы,
производительность и задвигаем на второй план простоту,
хороший дизайн, понятность, поддерживаемость.
Весь наш код разрабатывается только для того, чтобы он был самым быстрым
и максимально использовал все возможности нашего компьютера.
Но почему, собственно, это плохо?
Почему плохо сразу делать максимально быстро?
Потому что есть такой эмпирический закон, который известен как принцип Парето,
и он применим не только к программированию, а ко многим сферам
жизни, но в программировании его можно сформулировать как: 80 % времени работы
программы тратится на исполнение 20 % кода.
То есть вот именно от этих 20 % кода на самом
деле зависит производительность вашей программы.
И для того чтобы она действительно работала быстро,
оптимизировать нужно вот эти 20 %.
Но для начала их надо найти.
Если же мы будем делать максимально быстрым весь наш код,
то это, во-первых, достаточно тяжело, а во-вторых,
мы будем на это тратить время впустую.
И какие у нас от этого возникнут недостатки?
Мы необоснованно усложним код.
Ну, потому что чаще всего, если мы как-то ускоряем наш код,
то он от этого становится сложнее, потому что там какие-то появляются хитрые приемы.
А раз код становится сложнее, то его сложнее поддерживать,
ее сложнее рефакторить, переписывать и передавать другим разработчикам.
А все это приводит к замедлению разработки программы.
И поэтому получается такая интересная ситуация, что, с одной стороны,
вы вроде как разгоняете работу программы, но замедляете ее разработку.
И в таком случае вы можете написать самый быстрый код,
но слишком поздно, и он уже будет никому не нужен.
Если мои доводы вас не убедили,
то посмотрите еще на цитаты достаточно выдающихся людей.
Так, например, Дональду Кнуту приписывают вот такую вот цитату,
которая приведена на экране, в которой он сказал,
что преждевременная оптимизация — это корень всех зол.
Человек опытный — я думаю, ему можно поверить.
Также Уильям Вульф является автором тоже весьма интересной цитаты.
Я привел ее в оригинале, но попробую перевести: во имя эффективности,
которая при этом не всегда достигается, совершается гораздо больше грехов,
чем по любой другой причине, включая полную глупость.
Вот такая тоже интересная мысль.
Давайте подведем итоги.
Правило «избегайте преждевременной оптимизации» говорит нам о том,
что, как правило, по умолчанию код в первую очередь надо стараться
делать правильным и простым и только потом быстрым,
когда мы поймем, что наша программа работает медленно.
Но это не значит,
что в процессе разработки кода мы вообще не думаем о производительности.
Мы, естественно, когда пишем код, мы должны оценивать,
прикидывать, насколько быстро это будет работать, насколько это эффективно.
Но не рекомендуется ставить производительность во главу
угла как раз по принципу Парето — правило 80 / 20,
потому что мы в процессе разработки не знаем,
какой именно кусок кода у нас будет наиболее критичным.
