Comments 12
С профилированием сложнее всего в распределенных системах. И измеряющий производительность должен как минимум осознавать разницу между сэмплирующим и инструментирующим код профилировщиком.
А еще профилирование позволяет бороться с коллегами усложняющими проект там где не надо.
Есть книга, в которой описаны некоторые методы оптимизации: "Оптимизация программ на C++. Проверенные методы повышения производительности. Автор: Курт Гантерот". Кое-какие из перечисленных здесь методов там тоже описаны.
Там есть один важный совет: прежде чем что-то оптимизировать, подумайте, надо ли вообще это делать. Допустим, вы нашли кусок кода, который можно ускорить в 10 раз. Но если он исполняется всего 1% времени от исполнения программы, то никакого толку от оптимизации не будет.
А ещё иногда бывает полезно оценить трудозатраты на оптимизацию. Допустим, программу удаётся ускорить в 2 раза. Но если ради этого пришлось оторвать ключевого программиста от важных дел на неделю, например, стоит ли оно того?
Ожидал пункт 5: замена языка программирования / рантайма на что-нибудь более близкое к железу (и без GIL).
Давайте я подскажу ещё один, самый эффективный способ оптимизации, который вообще не требует никаких дополнительных ресурсов, не требует времени, и даже наоборот, зачастую круто экономит их:
Не усложнять без необходимости.
Это комплексное понятие. Включает в себя много практик. Например, не закладывать масштабируемость "на вырост", если она вам понадобится, когда нагрузка на ваш софт возрастёт в стопицот раз от нынешнего. Когда настолько возрастёт, у вас там вы и так бабло будете лопатами в вёдра складывать, с нуля заново перепишете.
Или, например, не делать зоопарк микросервисов, кубернетисы и так далее, если вы пишете ваш софт в три башки/шесть рук/тридцать пальцев.
Не цеплять сторонние библиотеки, из которых вам надо две-три строчки кода. И даже пять строчек кода. И даже десять. Просто напишите эти десять строчек кода.
И так далее.
Грамотная архитектура (разделение на слои, DI, отсутствие прибитых гвоздями связей, и т.д.)
Я не про отсутствие DI и не про реализацию всего и вся в контроллере. Если есть ORM, то два слоя, если нет, то три, и в общем-то этого достаточно.
Ах если бы. Когда "возрастает настолько", то заново переписать обычно нет времени - потому что продукт уже на рынке, конкуренты не дремлют, или заказчики требуют новые фичи, и переписывать всё с нуля вам просто не дадут
Ну, неправда ваша. Переписать уже приносящий деньги продукт, это практически всегда намного дешевле, чем с самого начала вкладываться в сложную архитектуру и отодвигать тот этап, когда продукт начнёт вам приносить деньги. Притом, что я вряд ли ошибусь, если скажу, что этак 90% продуктов с изначально заложенным дальним масштабированием до того масштаба и не доживают, и не последней причиной в том бывает слишком высокая стоимость начальной разработки, когда инвестиций не хватает для завершения проекта.
Тут примерно то же самое, что и в прошлом пункте - когда у вас масштабы (количество запросов, объемы данных, и т.д.) не слишком большие, то оверхед на работу зоопарка микросервисов и коммуникацию между ними себя не проявит,
Тоже неправда ведь. Он себя ещё как проявит, но только не в скорости работы вашего приложения, а в стоимости аренды и обслуживания инфраструктуры под него, а также в стоимости самой разработки. Вам это надо? А когда масштабы и сложность многократно вырастут, вы получите те же расходы, но помноженные многократно.
А если в языке линковщик умеет вырезать неиспользуемое и ненужное - то проблемы вообще никакой.
Даже в самом лучшем случае - вы получите ещё одну внешнюю зависимость вашего проекта, которую нужно учитывать при его сопровождении, и которая в какой-то момент времени может остаться без ментейнеров, уйти в легаси и так далее. Вам это надо?
Ну, неправда ваша. Переписать уже приносящий деньги продукт, это практически всегда намного дешевле
Правда в том, что 99% компаний верят в миф "переписать с нуля будет дороже, нужно здесь и сейчас" и... переписывают с нуля, только уже по другим причинам. Мне лично довелось работать в компании, в которой написали real-time data streaming на С++, потом переписали на Java "потому что падает", потом снова переписали на C++ и Python "потому что Java медленная". Попутно каждая переписка сопровождалась побочными проектами по созданию инструментов безшовной миграции.
Когда настолько возрастёт, у вас там вы и так бабло будете лопатами в вёдра складывать, с нуля заново перепишете.
Не цеплять сторонние библиотеки, из которых вам надо две-три строчки кода. И даже пять строчек кода.
Вижу здесь противоречие. Если мы хотим как можно сильнее ускорить написание первой версии, но брать библиотеки выгоднее. А уж потом если проект выстрелит и библиотека помрёт, то можно будет писать свой велосипед.
Давайте я подскажу ещё один, самый эффективный способ оптимизации,
который вообще не требует никаких дополнительных ресурсов, не требует
времени, и даже наоборот, зачастую круто экономит их
Это вообще не способ оптимизации ничего. Как правило, абстракции с которыми борятся свидетели YAGNI стоят крайне незначительно, а в тех задачах, где без абстракций действительно можно обойтись, перформанс никогда проблемой и не был. Я замечательно помню, когда этот вброс про тупую Алису, которая мучительно внедряла все известные паттерны в хелло-ворд, и умного Боба, который написал однострочник и поехал отдыхать на Гаваи, впервые появился на просторах. Видимо, виртуальный успех хитрожопого Боба до сих пор бударажит умы ищущих халявы. Это всё от неопытности. Где-то тут за скобками кроется предположение, что приложение, которое Бобу с Алисой требуется релизовать, оно простое и простым останется всегда. Но придется разочаровать Боба, в 2023м году никому не нужны простые приложения. Все простые программы уже давно написаны, а те которые не написаны делаются вообще без программирования конструкторами навроде Вордпресс.
Четыре способа оптимизации ПО