Комментарии 36
Вообще говоря, любое преждевременное что-то — зачастую корень бед, и оптимизация тут не стоит особняком. Я бы даже сказал, что сейчас маятник качнулся в другую сторону, и никакая оптимизация не выполняется даже там, где она нужна. Тормозящие сайты и непропорциональный рост системных требований это подтверждают.
На кризис ожиревших сайтов и 80 XHR запросов в Gmail явно повлияли преждевременные микрооптимизациии, в самом-то деле
Начали оптимизировать до того как поняли где же находятся ботлнеки системы — потратили время бесполезно. Пришло время релиза и откладывать уже ничего нельзя, система выходит как есть.
Если изначально известно что будет требоваться высокая производительность то лучше это учесть заранее. В геймдеве, например, переделать на data oriented design после будет сложнее чем заранее.
Важно понимать где именно узкое место в производительности, в некоторых случаях это можно определить заранее.
И применительно к JS это выглядит как издевка.
На худой конец уже давно как появился WebAssembly.
Брать WebAssembly там где он не нужен – еще одна преждевременная оптимизация. Вот пример.
Такое ощущение, что нынче вообще мало кто об оптимизации кода думает — хоть преждевременной, хоть своевременной. По крайней мере в сфере сайтостроения это постоянно вижу. Куда проще посоветовать заказчику железа прикупить.
Оптимизация затрат {для бизнеса) всегда была важнее. Просто раньше оптимизация кода была эффективным способом оптимизировать затраты, а то и доходы (программа, которая не поместится в 105 байт никаких доходов вообще не принесёт), а в наши дни зачастую есть более эффективные способы оптимизироаать расходы и доходы.
Беда только в том, что часто профайлер показывает более-менее равномерную размазанность медленности по большому куску кода (когда каждый отдельно взятый вызов занимает не больше 1%, например), и становится непонятно, как оптимизировать.
Так смысл статьи в том, что прежде чем что-то оптимизировать нужно стратегически убедиться, что оптимизируешь узкое место. С помощью профилировщика убеждаться, бенчмарков или ещё как — это тактика.
Имхо, случай преждевременной оптимизации — это когда в процессе написания кода жертвуешь его ясностью и временем на имплементацию в угоду воображаемой эффективности. А когда код уже написан — без профилирования что-то оптимизировать — это необоснованная.
Между чёрным и белым очень много оттенков серого, для кого-то один код будет преждевременной оптимизацией, для кого-то нет, все мы пишем по-разному.
В моём, почти 20-летнем опыте разработки, ни разу не было задачи что-то оптимизировать, что ранее было сделано неоптимально.стесняюсь спросить, но все же — какая область? какой язык программирования?
если изначально что-то не написать оптимально, оно ни когда не будет оптимизировано.
Для меня ценная мысль в том, что не проверив гипотезу — не двигайся вперед. Гуру берут в руки отладчик и профилируют ночами на пролет RC релизы, факт.
Та преждевременная оптимизация о которой писал Кнут относится к временам жестко ограниченных ресурсов и больше не актуальна. Сейчас никому не придет в голову считать каждый байт и каждый такт до того как в этом возникнет острая необходимость.
Сейчас чаще можно попасть в другую сходную ловушку, когда хочется все обобщить и создать красивую и правильную архитектуру кода еще до того как понял как это все будет работать.
Некоторым приходит, пускай не в тактах, а микросекнудах или и того меньше...
Такие ловушки я тоже отношу к преждевременной оптимизации, просто преждевременная оптимизация не времени исполнения или памяти, а преждевременная оптимизация гибкости, универсальности, переиспользования и прочего...
Сейчас никому не придет в голову считать каждый байт и каждый такт до того как в этом возникнет острая необходимость.
Вы недооцениваете человечество.
Не попадайте в ловушку преждевременной оптимизации