Comments 135
Полностью соглашусь!
О производительности нужно думать на этапе продумывания архитектуры. Вспомните Создателя — он придумал птицам, в числе прочего, трубчатые кости. Не стал их высверливать, увидев, что опытный экземпляр птицы способен лишь подпрыгивать, а придумал и сделал сразу )
Поэтому нельзя, проектируя аппарат передвижения по воздуху, “просто подкрутить что-то, или добавить памяти/ядер”, чтобы корабль стал самолетом. Не взлетит.
И ещё — посмотрите, как отличаются в фармакологии этапы создания препаратов, эффективные in vitro и in vivo. Между ними — «дистанция огромного размера». В инженерии все очень похоже — если опытный экземпляр с трудом оторвался от земли — то, чтобы серийный безопасно летал — нужно затратить ещё 10*X усилий. Поэтому если тестовая версия софта с трудом укладывается в требования по производительности — это не только не повод для радости, но и означает, что исходно требования по производительности не были «встроены» в архитектуру, и если кардинально ничего не поменять — то прод их гарантированно провалит.
Если у Вас есть бесконечное время, бесконечный бюджет, и бесконечная энергия — можно, конечно, превратить рыбу в птицу, внеся стохастику в модель наследования, функцию штрафа за ошибку, и самому наблюдать, просто покуривая в сторонке. Но в условиях ограничений приходится интенсивно впрыскивать внешнюю информацию в модель системы, чтобы сократить количество итераций ;). Что касается амфибий и прочих межсредовых комбинаций — оно не может быть одинаково эффективно в обеих средах так, как это делают нативные организмы или устройства. Поэтому в естественной среде (эволюция), или искусственно-организованном выживании (война) амфибии неизбежно вымрут
Эволюционная разработка то ли это что хочет заказчик? Типа отдам разработку трем мутантам и кто выжевет? Оптимизация на начальных тапах проектирование может быть практически бесплатной. А вто нет. Давайте запилим на PHP+Mysql а там может не взлетит и заказчик не догадается почему не взлетело.
Насчёт экраноплана не скажу, не в курсе. А вот с эволюцией ситуация такая, что кости были с пустотами ещё у динозавров. И судя по всему даже у предков динозавров.
Вот кстати аналогии с птицами тут могут не подойти, изначально крыльев и оперения ни у кого не было, они появились в результате множества этапов эволюции и развития.
Вот кстати аналогии с птицами тут могут не подойти, изначально крыльев и оперения ни у кого не было
Перья уже были у динозавров, крылья у некоторых из них тоже были и похоже, что некоторые из тех, что с крыльями, даже могли летать. У предков птиц уже было почти всё, что того, чтобы полететь. нужно было только немного подкрутить настройки.
Пасть там убрать, зубы всякие, хвост подрезать, крыло отрегулировать и так далее. С производительностью всё было уже готово. Включая производительную систему дыхания. И производительный мозг.
Вспомните Создателя — он придумал птицам, в числе прочего, трубчатые кости. Не стал их высверливать, увидев, что опытный экземпляр птицы способен лишь подпрыгивать, а придумал и сделал сразу )
Вообще, нет, не сразу. Это как раз побочная фича. Боженька сначала сделал архозавров, которые, оказавшись удачными доминирующими видами, стали основательно отжираться и расти в размерах, и возникла проблема облегчения тушки, чтобы оно не сломалось. Тогда боженька стал смотреть, где можно что выкинуть, и придумал пневматизацию костей, ну т.е. чтобы эти здоровые кальциевые штуки были не цельными, а с воздушными полостями внутри. Получилось неплохо, тушки до 20 метров стали отрастать. Заодно, чтобы мелкие тушки не замерзали (у крупных проблема терморегуляции сама собой решилась), боженька добавил им пуха, перьев всяких. Получились динозавры. Но потом они согрешили как-то, и боженька наслал на них
а) облегчённые тушки
б) оперение для маневрирования
И стали с их помощью сначала эффективно драпать/прыгать с деревьев от начинающих наглеть синапсид. А потом прокачали скиллы, и стали летать. Так что нет, птички, это когда старая фича нашла новое применение.
читал как увлекательный триллер! Пишите еще!
Могу я написать? На дня появилась идея и не знаю вот с кем обсудить.
Думал про "что было первее — курица или яйцо", почитал в сети и оказалось, что точно не установить. Но зато появились мысли как могло появиться яйцо любого существа, необязательно курицы или динозавра.
Выкидыши во время беременности случаются у всех существ во все времена, даже бывают дефекты в генах у женщин, увеличивающие их частоту.
Так вот, когда-то у какого-то беременного существа на каком-то сроке случился выкидыш. Ничего необычного, но плод не только выжил, но потом смог оставить потомство, беременность которого тоже закончилась выкидышем и выживанием потомства — фича закрепилась.
Что это дало? Немного сократился срок беременности, т.е. беременное получило небольшое преимущество в том, что может чуть меньше обременяться беременностью и заниматься другими важными вещами — выживать и искать партнёра, чтобы снова забеременеть.
Почему же плод выжил? Скорее всего, он доразвивался до обычного новорождённого из-за питательных веществ, которые остались либо в маточной слизи, либо в нём самом.
В итоге круг оптимизации сформировался — стало выгодно оставлять всё больше питательного для плода, чтобы "выкидывать" его на всё более ранних сроках, чтобы быстрее освобождаться для выживание и новой беременности.
Одновременно с всё меньшим сроком развития и всё большим запасом веществ росла и защита плода — чаще выживали те, кто рождался с всё более прочной покрывающей слизью, а потом и твёрдой оболочкой с нужной формой. Внутренним органам будущей курицы тоже пришлось меняться, чтобы легко выводить уже не мягкое тельце, а всё более твёрдый предмет покрупнее.
Таким образом, вполне сформированное новорождённое животное со временем деградировало назад до предела — в "бульон" из питательных веществ-материала внутри твёрдой оболочки, в беременность вне тела.
Как философия Unix — пусть программа делает только одну вещь, зато хорошо. Предкам курицы оказалось неудобно выживать "с животом" и они разделились.
Вы говорите так, будто откладывание яиц более продвинутая форма, чем живорождение, но опыт показывает обратное.
Яйца — это развитие истории со спорами/икринками/etc
Почему курица до яйца не могла быть живородящей? Потому что это уже не будет курицей?
Тогда что мешает так же родиться курице из яйца, которое нельзя классифицировать как куриное? Например, оно не той формы, не той прочности, чуть другой состав...
Если принять, что яйцо годится любое, тогда почему нельзя принять и любую курицу?
Если внести уточнение — «курица или куриное яйцо» — задача не имеет решения. Эволюция (постепенное ползучее изменение облика от поколения к поколению) идёт настолько медленно, что невозможно найти чёткую грань между «пракурицей» и «курицей».
https://ru.wikipedia.org/wiki/Проблема_курицы_и_яйца
Тогда что мешает так же родиться курице из яйца, которое нельзя классифицировать как куриное?
То, что яйцо — это уже курица. Зародыш курицы, если быть совсем точным.
-Что было первее — яйцо или курица?
-Яйцекурица!
Курица вполне могла родиться из нестандартного яйца, они и сейчас так делают.
По-дилетантски предположу, что наверно можно даже генетическими методами родить курицу из страусиных или крокодильих яиц, если в них есть нужный состав.
Курица могла родить цыплёнка в плёнке — первый вид яйца.
Эта фраза разве относится конкретно к курицам? Она относится к первым существам, способным откладывать яйца. Первые динозавры или их предки откладывали яйца с мягкой оболочкой: https://in-space.ru/myagkie-yajtsa-perevernuli-predstavlenie-ob-evolyutsii-dinozavrov-i-gigantskih-reptilij/
Из логики, что незачем обсуждать были ли яйца до того, как они потом снова появились.
Обсуждаем, что раз яйцо появилось, значит его создатель не был сам из яйца. Были ли яйца до них — к обсуждению не относится.
Поэтому для упрощения проблему можно отнести к первому появлению яйца, чтобы не уходить в оффтоп.
Яйцо и курица условны, вместо них можно подставить и икринку с рыбой, компилятор и его собственный исходный код, который он может скомпилировать...
Почитайте как работает эволюция. Сразу вопросы отпадут.
Яйцо как способ размножения появилось намного раньше кур. Согласно современным взглядам, птицы являются эволюционными «потомками» пресмыкающихся (динозавров), уже размножавшихся яйцами задолго до начала процесса эволюционной трансформации некоторой части динозавров в птиц. В условный исторический момент возникновения класса птиц было снесено яйцо, из которого позднее вылупилась «птица». В то же время, более широкое трактование позволяет под «яйцом» понимать схожие с ним по строению и функциям биологические объекты (икра рыб, земноводных, яйца пресмыкающихся, в том числе имеющие твердую оболочку). Но широкая трактовка предполагает, что ранее должны были появиться живые существа, которые потом в процессе эволюции приобрели способность размножаться с помощью яиц
Какой момент вас смущает?
Меня как раз ничего не смущает.
Яйцо как способ размножения появилось намного раньше кур.
И потом почитайте, откуда берется изменчивость в биологической эволюции.
Отсюда станет очевидно, что первое яйцо с зародышем курицы отложила "недокурица".
Что по вашему "курица"?
Чем ещё она, вырастив из этого яйца, должна отличаться от "недокурицы"-родителя, кроме как способностью кладки яиц?
(забавно, что мы обсуждаем то, что обсуждают тысячи лет разные философы и учёные, что названо в Википедии" проблемой". Будто мы сейчас вдруг решим этот вопрос)
В Википедии упомянута "пракурица", но почему-то не упомянуто "праяйцо" — вот в чём ещё проблема.
Пракурица родила праяйцо и далее они эволюционно развивались вместе до курицы и яйца. И нет возможности определить кто из них развился быстрее, т.к. нет резкого перехода между пракурица -> курица и праяйцо -> яйцо, т.к.
Эволюция (постепенное ползучее изменение облика от поколения к поколению) идёт настолько медленно, что невозможно найти чёткую грань
Это какого создателя? Рода, Брахму, Ади Шакти, Саваофа?
Кто из них трубчатые кости придумал, я что-то запутался :)
Ох уж этот превозносимый тайм ту маркет.
Мне кажется (с точки зрения пользователя) что лучше бы подавляющее большинство софта не вышло на рынок вообще.
Ситуация, когда откровенно паршиво технически реализованное решение выходит на рынок и успевает занять более менее заметную его часть — ужасна.
Потому что "эффективные" менеджеры никогда не выделят ресурсы на ускорение работы софта пока из-за тормознутости последнего от вас не уходят клиенты, а клиенты от вас не уходят потому что других альтернатив немного.
Получается классическая ситуация "давайте накрапаем прототип на питончике силами двух студентов пишущих сортировки за квадрат, главное чтобы быстрее на рынок вышли", а через два года "у нас такая большая кодовая база что переписывать её на плюсы мы не будем, потому что для этого нужно слишком много ресурсов и времени, лучше добавим еще одну такую же тормозную фичу".
Причем если проанализировать насколько быстрее вы выходите на рынок жертвуя качеством своего продукта — счет идёт максимум на месяцы, и не так уж и много ситуаций когда существует реальная гонка где вы с конкурентами дышите друг другу в затылок.
Отсюда и ситуации когда фейсбуку и вконтакту легче переписать PHP чтобы он тормозил поменьше чем свою кодовую базу на нормальный язык.
Качество разработки и заключается в нахождении того баланса, где мы можем сейчас срезать угол чтобы быстрей уйти в прод, но при этом было бы потом не тяжело рефакторнуть это место для лучше производительности в случае необходимости.
П.С. шутки над производительностью PHP уже малость устарели.
Надо снять пару роликов, как стартуют студии от 6.0 до самой современной. Пользователи охренеют..
Достаточно посмотреть на какой-нибудь нейросетевой super resolution фильтр — требует гигабайты места, на каждую картинку без мощной видеокарты уходит минут по 20 — но качество несравнимо по сравнению с любыми lanzcos и иже с ними методами увеличения разрешения.
То же и со студией — всякие подсветки, проверки, анализы кода и иже с ними, которые очень помогают в работе, как раз и замедляют работу. А стоит поставить какую-нибудь Express-версию, в которой это всё отключено — и всё летает.
И в режиме отладки свои анализаторы, которые также выполняют полезную работу, вроде вычисления значений кастомных переменных или показа результата выполнения какого-то нетривиального геттера в классе.
Отладка сейчас и отладка десяток-другой лет назад сильно различаются.
но при этом было бы потом не тяжело рефакторнуть это место для лучшей производительности
Всё дело в том что "этим местом" обычно оказывается весь проект. Пол миллисекунды времени загрузки конечно не стоят того чтобы корпеть над ними пол года, но пол секунды времени загрузки страницы или выполнение какой-то основной операции вдвое быстрее — стоят.
Да вся проблема на самом деле в том что как только собрана версия из говна и палок она сразу же обрастает фичами и горами пахучего кода, вероятность переписывания которого неуклонно падает со временем. Сама концепция того что код переписывается трижды — сперва чтобы работал, потом чтобы работал правильно, а потом чтобы работал быстро — работает только в вакууме, с бесконечными ресурсами и без давления менеджеров на инженеров.
Тезис про растерять всех клиентов к моменту выхода продукта — лично для меня спорный, не многие продукты анонсируются заранее и лишь малая доля проектов участвует в реальной "гонке к рынку". Обычно вы делаете продукт который просто появляется в определенный момент не зависимо от внешних условий, и месяц разработки который вы потратите на грамотный выбор архитектуры, инструментов и написание качественного кода окупится с лихвой уже в первый год жизни проекта.
SaaS продукты потом таки переписывают отламывая по кусочкам сервисы от монолита на PHP или Руби (почему-то, очень многие начитают именно с этих языков).
Напомнило https://xkcd.com/1205/
В последнем как раз и был случай, когда клиенты появились раньше как такового готового продукта и проект быстро писался в полу-авральном режиме дабы клиенты не успели уйти к конкурентам. Благо в том случае не успели понаделать критических ошибок и в дальнейшем переписывать и рефакторить с умом была возможность.
Как пример проекта где промедление и долгое раздумие «а как же сделать правильно» с высоким риском ситуации «мы думали что будет работать так, но оказалось что нет», привело бы к смерти компании.
Естественно, думаю как и у большинства, были проекты где единственным решением было полное переписывание приложения из-за крупных архитектурных ошибок т.к. оптимизацию задвинули в дальний ящик.
П.С. я отталкивюсь от понимания того что термин «оптимизация» это не только Производительность, но и архитектура приложения по фен-шую
Не понятно, в чем претензии к Вконтакте/Фейсбуку? Вроде бы они сильно не тормозили никогда, с точки зрения пользователя (у Фейсбука одно время было невероятно жирное мобильное приложение, но там проблема была в технической архитектуре а не в том, что хотели выпустить побыстрее).
Я думаю ваша позиция имеет смысл когда продукт — технический, например, база данных или фреймворк (типа, MongoDB). В других случаях, тайм-ту-маркет или нет, продукт может быть просто плохим вне зависимости от производительности, но это к оптимизациям не сильно относится.
Конечно, надо заранее думать о производительности, и соотвественно выбирать инструменты. Но практически во всех проектах, в которых участвовал, производительность подгоняли уже после того как вышли в продакшн или на поздних этапах.
И если следуя из моего опыта, так или иначе придется позже заняться производительностью, то какой смысл заниматься этим на ранних этапах? Бесмысленно. Лучше сделать быстрее рабочий вариант, с минимвльным набором функционала, что бы погонять на реальных данных, и в реальных условиях, которые могут значительно отличаться от того, что у вас в голове, чем сразу придумывать супер пупер оптимизацию. Как то в одном проекте видел такую ранюю оптимизацию, кэширование PreparedStatement, больше человеку в голову не пришло. Типа улучшит производительность, ага. А после написанные SQL запросы, этим же человеком отрабатывали по минуте или две. К чему было тратить время?
Да и на ранних этапах неизвестно какие бизнес кейсы будут позже реализованны и в итоге все равно поломают вашу оптимизацию и возможно придется все переделывать.
Плюс «оптимизированный» код труднее отлаживать. Неоптимизированный выглядит проще, проще в нем разобраться. Уж правда, лучше сначала сделать все рабочим, что бы удовлетворяло требованиям, чем супер быстрый код, но не работающий как ожидается.
Конечно, надо заранее думать о производительности, и соотвественно выбирать инструменты.
Речь не идет о том, чтобы «не думать о производительности». Речь о том, что в процессе разработки сначала «правильно», потом «быстро».
В противном случае будет тратиться время на оптимизацию «неправильного» кода.
«Неправильным» код может быть по нескольким причинам — ошибки в разработке (баги), ошибки в требованиях (аналитик не понял заказчика), ошибки в архитектуре (например, выбранные технологии не могут быть использованы заказчиком в силу ограничений законодательства).
Правильным решением будет разрабатывать архитектуру с продумыванием возможности оптимизации узких мест в будущем, чтобы не получилась ситуация, что программа тормозит, но оптимизация потребует переписывания половины кода.
В случае с энтепрайзом, могут случится казусы, а-ля: вот это вот базочка, для вспомогательных нужд, тормозит каждый запрос. Потому профилировать и потом оптимизировать, а не строить предположения.
Опять же, если это позволяет выкатить фичу пользователям и уже завтра зарабатывать деньги, а потом после завтра получить довольных пользователей, которые скажут: «огонь, производительность стала лучше!», то почему бы это не выкатить? С другой стороны сама фича пользователям может не зайти, так стоит ли упарываться и и тратить овермного времени на вещи, которые ты послезавтра выкинешь?
Прежде всего — это довольные клиенты/пользователи.
Пока не произойдет следующее:
— самочки начнут давать предпочтение куликам, которые больше всех скопили еды;
— кулик захочет, расширить свою территорию на другие болота, что бы получить больший доступ к самочкам, а там свои предпочтения;
— с соседнего болота привалят кулики, которые перехватывают самочек в водухе, и делают свои дела и не запариваются с выращиванием потомства.
Может статься, что в процессе погони, за красными кончиками на хвосте, кулик, совсем разжиреет, потому что у него самые красные точки, и самочки сами его кормят. Но в какой-то момент, самочки могут захотеть пойти к более стройным куликам. И жирный кулик, окажется за бортом размножения, если не похудеет вовремя.
В это время, тоннами стройные, подтянутые кулики, остаются за бортом размножения, потому что самочке кулик без крапинок не интересен от слова совсем.
Резюмиру.
У индустрии есть 2 локальных проблемы:
— решение задач которые, нафиг никому не нужны;
— плохо решенные задачи, которые создают слишком много проблем в будущем.
Идеальный код, никому не нужен, кроме самого разработчика. Есть пользователи, которым нужен быстрый код; есть те которым нужен красивый интерфейс; есть те, которым на все плевать главное, что бы батарейки до вечера хватало. А решать задачу про сферического коня в вакууме, это к перфекционистам. Пока они будут вылизывать код, я буду смотреть на довольных пользователей и банковский счет. Пока идеалистам не захочется кушать, ведь они не продали свой продукт, потому что он не идеален.
Another important aspect of program quality is the efficiency with which the computer's resources are actually being used. I am sorry to say that many people nowadays are condemning program efficiency, telling us that it is in bad taste. The reason for this is that we are now experiencing a reaction from the time when efficiency was the only reputable criterion of goodness, and programmers in the past have tended to be so preoccupied with efficiency that they have produced needlessly complicated code; the result of this unnecessary complexity has been that net efficiency has gone down, due to difficulties of debugging and maintenance.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
We shouldn't be penny wise and pound foolish, nor should we always think of efficiency in terms of so many percent gained or lost in total running time or space. When we buy a car, many of us are almost oblivious to a difference of $50 or $100 in its price, while we might make a special trip to a particular store in order to buy a 50 cent item for only 25 cents. My point is that there is a time and place for efficiency; I have discussed its proper role in my paper on structured programming, which appears in the current issue of Computing Surveys
Это заявление вовсе не про то, что оптимизацией можно заняться потом. Оно о том, что время программистов дорого. И нужно трезво оценивать стоит ли тратить своё время на вылизывание кода и стоит ли оно того. Если оно того стоит, то вылизывать нужно сразу. А если оно того не стоит, то у программиста никогда не будет свободного времени на рефакторинг никогда. Работодатели не дураки, чтобы впустую сжигать свои деньги.
Я не читал текст, из которого взята цитата (возможно, ответ там), но непосредственно из цитаты не могу понять, откуда вы берёте утверждение про "вылизывать сразу" и никогда "не будет времени на оптимизацию". Не могли бы вы пояснить? Спасибо!
Кнут работал на уровне ассемблера.
Т.е думаю его слова сейчас напрямую относятся к разработчикам на Adruino или STM32 или чем-то подобном, т.е. малым встраиваемым системам.
Действительно когда кодируешь под микроконтроллер все время стараешься писать наиболее быстрые алгоритмы. Это как навязчивая мания, когнитивное искажение.
Потом оказывается что тормозит вовсе не то, что отняло столько внимания.
Но избавиться от него невозможно даже отлично зная советы Кнута, потому что есть что-то в психике.
Т.е. Кнут высказал не рекомендацию, а отметил медицинский факт.
Люди не перестанут ехать на другой конец города в другой магазин ради экономии пары центов.
Я считаю эту логику ошибочной. Если ваша программа все еще является прототипом и выполняет, например, 1% (20%, 50%, 90%) того, что она должна делать, и она уже работает медленно, то она будет еще более медленной после того, как вы ее закончите, разве нет? Если вы заставите ее делать больше, почему он должна стать быстрее?
Мне кажется что проблема тут. Прототип нужно выкинуть и начать писать программу «как надо», а не пытаться оптимизировать изначально плохую архитектуру.
Слишком поздняя оптимизация — зло.
Несвоевременная оптимизация — зло.
Слепое и догматическое следование любому принципу, включая этот — зло.
… и?
Проблема в том, что часто от создания действующего макета до итогового продукта всё значительно меняется несколько раз (например, оказывается, что в реальной жизни тут не одна сущность, а пара, в отношении 1-к-многим). И каждый такой раз есть вероятность, что преждевременная оптимизация:
1. Будет усложнять корректировку под изменившуюся задачу.
2. Будет выброшена на помойку.
Речь идет о том, что пока не просматривается конечная форма продукта, со всей его окончательной функциональностью — нет смысла оптимизировать отдельные части. Ровно потому, что любая из них может быть или переписано заново и принципиально, или вообще в окончательный вариант не войти! На кой черт ее тогда «оптимизировать»?
Это конечно не значит, что не нужно думать о производительности совсем — можно и нужно, но исходя из знаменитой формулы 80/20 и здравого смысла…
Проблема того, что в итоге из-за сроков и суровых законов рынка в продакшн выходит нечто совсем без оптимизации — это проблема менеджмента, а не правильности разработки.
В реальности — это ряд проектов/продуктов, и в общем случае контроль над кодом и возможность его изменить в любой момент важнее, чем сложный оптимизированный кусок, в котором сложно поменять логику.
В случае же выбора JS/C++ — то это уже не про оптимизацию кода, а про выбор инструмента. А инструмент выбирается под задачу исходя из многих вводных.
Во мне интересно, почему разработчики которые ниасилили ни одного из томов Кнута и даже не собриаются этого ниикогда делать в принципе так схватились за эту единственную вырванную как всегда из контекста фразу. Фраза дествительно скорее вреднаы чем полезная потому что афористичная и запоминающаяся. И исходит от непререкемоготавтоиртета. Ве как раз идеально для того чтобы использовать ее в некорректных спрорах.
прототип должен иметь производительности ровно столько, чтобы её было достаточно для отладки — чтобы тестировщики и разработчики на своём (топовом!) железе не мучались из-за этого — и ни на йоту больше.
Сделать больше — и художники, моделлеры и левел дизайнеры сразу насуют столько дополнительных элементов и полигонов, что никаких резервов производительности не останется — из-за чего попытка оптимизировать для слабого железа вроде старых консолей превратится в ад.
чтобы тестировщики и разработчики на своём (топовом!) железе не мучались
Но зачем давать тестовому стенду топовое железо, в таком случае? Не лучше разве определить некоторое среднее, и потом для стенда взять на условно один-два шага более мощное железо, чтобы по принципам догфудинга сами разработчики и тестировщики из первых рук видели, где и как что-то тормозит.
Производительность оставляют на потом, но "потом" часто не случается, так как нужно пилить новые фичи и времени на переписывание нет (и дорого это).
Поэтому масштабируемость нужно сразу закладывать на этапе проектирования. Что не нужно делать — так это заниматься оптимизацией каждой отдельной небольшой функции, есть и такие любители.
А потом получается, что кому-то легче тесты разбить на группы и распараллелить чем сделать так, чтобы запрос в базу не длился по 12 секунд на тестовом наборе данных. Я не программист, но не верю что это «нормально». А для кого-то это «нормально». Однако «нормально» и «я не знаю как это исправить» две разные вещи.
Вот еще история.
Мы как-то писали новый набор тестов, и выпытали у разработчиков, что у приложения есть API, и получается, в тех тестах, где создание бизнес обьекта через формуляр не является предметом теста, его можно создавать через вызов API, вместо UI, и экономить 20 секунд в каждом тесте. И молодой автоматизатор сказал: «Да какая разница, оно же все равно ночью на сервере работает. Вот когда за 8 часов перевалит тогда и будем думать.» Я, в педагогических целях, ответил, мол, ну, ладно, давай так, посмотрим.
Вскоре выяснилось, что самому при проверке этих тестов мешает когда они исполняются лишних 20 секунд в том месте которое не интересует. И на презентации неудобно когда 40 человек лишних 20 секунд молча пялятся на экран там где ничего связанного непосредственно с новыми проверками не происходит.
Так задачи по оптимизации времени исполнения, быстро, как пузыри в джакузи, поднялись в беклоге и были вставлены в ближайшие спринты. И все остались довольны.
Я это к тому, что вообще возможно ли в огромных проектах оптимизировать производительность сразу?
Мой вывод таков: если вы хотите создать действительно быструю программу, с самого начала обращайте внимание на производительность.
Если же для программы производительность не критична, то и не заморачивайтесь.
Как обычно — кто-то в интернете что-то написал. А потом народ пытается это опровергнуть или подтвердить, пока настоящие синьоры пишут код и решают проблемы )
А если серьезно — автор неправ. Конечно, лучше работающая программа, но медленная, чем быстрая, но некорректная. Поэтому лучше сначала разработать прототип, а потом уже понять — где узкие места и их отрефакторить. Тем более, что уже будут нормальные тест кейсы и понимание области применения и ожиданий пользователя
Хотел откомментировать корневой пост, но Ваш комментарий, в принципе, передаёт и мои мысли.
Действительно, гораздо важнее написать корректный код и покрыть его тестами. Так вы обретаете широкую свободу изменять код (оптимизация, прочий рефакторинг) не боясь поломать корректную логику.
Кстати, по поводу скорости. Вообще говоря, а как вообще понять что программа тормозит? Нужны метрики скорости для начала. Очевидно, чтоб добавить такие метрики нужен некий готовый код. Возможно, самая наивная реализация будет достаточно быстра для типичного использования. Так зачем напрягаться?
И не забываем про принцип Парето. Оптимизировать имеет смысл только самые «горячие» участки кода.
Иными словами, наиболее эффективно можно ускорять что-то осязаемое, причём закреплённое тестами и покрытое метриками производительности. Без этого писать абстрактный «быстрый» код — гиблое дело. Зачастую эти оптимизации будут путаться под ногами и всеми силами мешать, пока вы будете пытаться достичь целевого функционала вашей программы.
Отличный доклад на эту тему с какого-то из джокеров: https://m.youtube.com/watch?v=EupF3VNXPPQ
"99% процентов перфомансной оптимизации — это исправление ТУПЕЙШИХ ошибок"
Да, верное замечание. Есть даже принцип такой https://ru.wikipedia.org/wiki/Чем_хуже,_тем_лучше.
Чтобы правильно оптимизировать, нужно нырнуть в будущее и увидеть, какие фичи вы добавите и как твоим решением будут пользоваться пользователи, иначе ты выкинешь свое время в мусорку на оптимизацию совсем не узкого места, а то и хуже сделаешь. Например, накинешь кучу ненужных индексов в базу, замедлив вставку. А ты знаешь, какие данные будут в будущем в бд? Не совсем. Возможно, будет достаточно 1 индекса и он будет супер селективным.
Но забивать на производительность в очевидных местах — тоже неправильно.
Мой вывод — нужно знать меру и не уходить в крайности
Если ваша программа все еще является прототипом и выполняет, например, 1% (20%, 50%, 90%) того, что она должна делать, и она уже работает медленно, то она будет еще более медленной после того, как вы ее закончите, разве нет? Если вы заставите ее делать больше, почему он должна стать быстрее?
Авто тут зачем-то смешивает производительность и оптимизацию, а это два разных понятия. Кнут имел ввиду, что для начала надо придумать архитектуру программы и реализовать функционал, а уже потом полировать и оптимизировать код глядя с высоты готовой программы.
Производительность же почти всегда определяется заложенной архитектурой и зачастую значительное ее улучшение представляется приличной проблемой.
Ответ прост. Надо быть просто умным, и тогда вы сделаете оптимально.
#irony
Без объективных критериев подобные советы почти бессмысленны, а критерии у каждого в голове свои и к тому же все программы разные.
Почему почти? Ну можно переформулировать так:
«Программист! Увидел возможность оптимизации? Не используй её, не дописав программу до рабочего состояния!»
Раз все обсудили, я пройдусь по переводу: "Я говорю, что эти улучшения случайны. Им просто повезло. Они могли никогда не случиться так легко, как раньше". Серьезно? Статья написанная по-английски русским переведена на русский и все равно осталась на английском. Горшочек переводов, не вари! К счастью, целиком перевод с основном нормальный.
Тормозили и глючили безбожно.
Т.к. при «оптимизации» использовалось куча грязных хаков.
Благо FoxPro и Clipper это позволяли.
Которые не давали нормально рефакторить код, без переписывания всего приложения.
ИМХО в начале нужно писать «чистый код».
Только потом, когда программа работает, искать узкие места.
Которые, если код написан «чисто», достаточно легко изолировать и оптимизировать.
«Преждевременная оптимизация — корень всех зол» — это корень всех зол.Хорошо сказано. Современный софт страдает от ожирения. Точнее, дикого, безбожного ОЖЫРЕНИЯ. Ожирение ведёт к большой куче проблем, которые выходят далеко за рамки производительности (в т.ч. страдает надёжность, функциональность и т.п.). Тонны жира оправдывают «сначала сделаем программу рабочей, потом (никогда) — быстрой». Так что про корень всех зол близко к истине, весьма…
ожиревший софт не может быть качественным…
Ввести определение «ожиревшего» как априори некачественного, а потом гордо утверждать «софт, который я назвал некачественным, не может быть назван мной качественным» — это очень удобный способ поучаствовать в диалоге, ничего в него не добавив, да. :)
Иными словами — куда полезнее было бы чётко определить критерии ожиревшести, качественности и некачественности, чтобы окружающие могли как-то отвечать.
Чем вообще можно занять ГИГАБАЙТ памяти? У меня никакой фантазии не хватает!
Впихивал вебморду железки со всем стеком в ATmega64 (64 КБ ПЗУ + 4 КБ ОЗУ) — да вполне свободненько влазит. Без всяких ассемблеров даже (ну почти). Открывали для тестов сотню вкладок на нескольких компах — работает, с динамическим обновлением по XHR…
Ну ладно, серьёзный софт требует больше ресурсов на несколько порядков. Но я всё равно не понимаю куда можно потратить несколько гигов!
Почему запросы растут по экспоненте, а функциональность — на проценты? А то и вообще серьёзно падает?
А ведь все эти гигабайты непойми какого хлама — явно содержат помимо каких-то непонятных телодвижений ещё значительный процент багов и глюков!
Потому что в случае с программными продуктами есть опция "выпустить патч". В случае с железом такой опции нет. Вот поэтому и разные требования.
В заголовок вынесен принцип, который очень опасно абсолютизировать, и да, я полностью согласен с Кнутом.
И с тем, что 12 процентное повышение производительности, легко получаемое, никогда не сочтут незначительным, тоже согласны?
Я написал ровно то, что написал.
Вы написали, что полностью согласны с Кнутом, а я процитировал Кнута. С этой цитатой вы, как я понимаю, тоже согласны.
Ну камон, это какое-то агрессивное передёргивание слов оппонента
Ну нет )). Это агрессивная попытка побудить оппонента прямо сказать, что он с цитатой из Кнута не согласен )).
вполне понятно же, что человек имел в виду
Вроде понятно. Но и позиция того же Кнута, она немного сложнее, чем многие думают. Цитата про 12 процентов, она, кажется на предыдущей странице по отношению к цитате про преджевременную оптимизацию.
Хотел написать тоже самое, про "категорически не согласен с автором", но вы меня опередили. Я лишь хотел бы немного раскрыть моё (и надеюсь чуть более исходное) понимание фразы, как минимум в двух факторах.
В-нулевых, нужно понимать временной контекст. Семядисятые были специфичным временем, когда ещё перфокарты не вымерли. Подход к проектированию ПО был совсем другим. Всё таки изначально было бы не плохо пройти итерацию формальной верификации, и только потом, осторожно заменять узкие узлы какими-то хитрыми оптимизациями. Почему? Потому-что эти самые оптимизации обычно заключались в ручном разворачивании циклов, хитрой математики с батчингом, сворачиванием ветвлений в более сложные, интересной булевой алгеброй, и крайне сложные к пониманию эврестически алгоритмы, на которые ещё и корректность изначально выложить доказательство.
Поэтому, во-первых, есть понимание сей цитаты как нечто, что может испортить изначальны замысел. Переусложнение кода и непонятные побочные эффекты. Данный тип предостережения является крайне важным в том смысле, что если его не следовать, то можно получить плохо читаемый код с неочевидными ошибками. Подозреваю, что это в принципе изначальная мысль, хотя это не точно.
Во-вторых, это может оказаться банально ненужным, лишняя трата энергии. Если очень условно и притянуто за уши, то вместо пузырьковой сортировки (ну или сортировки вставками) реализовать quick sort. А потом узнать, что размерность сортируемого множества никогда не доходит до тысячи. Или реализовать quick sort множества по запросу (лениво) множества на чтение, но окажется, что записи в целом происходят намного реже чтений, поэтому намного выгоднее может оказаться хранение деревом (особенно, если записи не подверженны изменениям).
Но это сова на глобусе, в реальности проблемы могут быть куда глубже. Что в целом, вполне можно заметить на старых и современных файловых системах — разные проблемы решаются совсем по разному. Или, вот, графический конфейр раньше был блокированный чтобы избежать сложности с конкуренцией (и более быстрыми вызовами, ессно). С развитием многопроцессорных систем это стало атавизмом, который очень сильно замедлил переход игровой индустрии на многопроцессорные (читай, многоядерные) системы.
А по-моему, производительность нужно добавлять только после того как продукт начинает тормозить настолько сильно, что перестаёт быть пригодным к работе. Просто в ваших роботах-боботах этот момент наступает после задержки в десяток миллисекунд, а в энтерпрайз вебе — после задержки в десяток секунд.
Я не вижу никаких проблем ни у себя, ни у окружающих программистов сделать какую-угодно прихоть клиентов:
- Хотите быстро — пожалуйста
- Хотите надежно — пожалуйста
- Хотите производительность — пожалуйста
Проблемы начинаются там, где программистов в первый год разработки только гонят по срокам реализации новых фич, а потом, через год, начинают спрашивать «а почему так много багов?», «а почему все так тормозит?» и у программистов, почему-то, не хватает смелости сказать очевидную вещь: а что хотели, то и получили!
Есть даже такой классический развод «функционал бонусом», когда в ТЗ указано 10 пунктов, а потом, в процессе, заказчик хочет еще 5 пунктов за те же деньги и сроки, и доказывает, что они «само-собой разумеющиеся». Детская разводка, которая, к сожалению, очень часто срабатывает.
Но факт в другом — человек, который поддается на разводы, в любом случае будет виноватым. Каким бы он не был классным, сколько бы выходных он не проработал сверхурочно.
Проблемы начинаются там, где программистов в первый год разработки только гонят по срокам реализации новых фич, а потом, через год, начинают спрашивать «а почему так много багов?», «а почему все так тормозит?» и у программистов, почему-то, не хватает смелости сказать очевидную вещь: а что хотели, то и получили!
Подписываюсь. По моему опыту заказчикам на первых этапах разработки очень сложно решиться разменять время разработчиков на более качественную работу. Работу с требованиями, работу над разработкой решения которое будет не таким лобовым и тормознутым. Конечно, со стороны заказчиков тоже есть причины, по которым они и делают этот выбор. Но это удивление, в определенный период жизни проекта, когда вылезают минусы принятого раннее решения — выглядит по-детски.
Производительность главнее всегоГлавнее всего — качество, в котором производительность — одна из неотъемлемых составляющих.
К сожалению в реальности низкая производительность пробирается в интерфейсы и сервис/класс/функция вообще не могут быть хорошо оптимизированы без изменения API. Вспоминая недавнюю историю R*, если функция-геттер опции конфига получает многометровый конфиг в виде zero-termiated строки, то она не может работать быстро.
Или чуть более C++ специфично. Если объект в метод принимает char* или string_view, то он вынужден копировать эту строку, так как не имеет гарантий на срок жизни.
То есть не надо тратить время на супер оптимизированные алгоритмы, но надо задумываться о том, как их потом внедрять.
Почти все споры – споры о терминологии. "Преждевременная оптимизация – корень всех зол", "преждевременная" не значит "любая" и не значит "до окончания всего функционала".
С одной стороны потерять месяц на оптимизацию компонента, занимающего 10% времени выполнения глупо. С другой стороны разрабатывать систему обработки петабайтов потоковых данных в день изначально на PHP тоже не самая умная идея.
Ну и не забываем о том, что самый быстрый код обычно труднее всего читать и поддерживать.
Мне кажется думать о производительности следует на стадии дизайна системы, оптимизировать же конкретные функции и компоненты следует только когда есть повод считать их узким местом.
Согласен и с Кнутом и с автором. С Кнутом — что когда создаешь объёмное приложение стремление к идеалу может завести в долгие дебри и проект застрянет надолго. С автором, что в работе никогда не упускать из виду цели на производительность, что на деле представляет из себя другой подход к разработке, который может и занимает на 20%-30% больше времени, но позволяет создать в несколько раз более производительное приложение. И при кодинге я всегда делаю замеры на скорость, ведь даже на простых запроcах к БД можно можно на порядок или на два ускорить выполнение — просто изменив кострукцию запроса, учитывая особенности работы СУБД. Аномальные задержки достаточно просто увидеть и переделать при написании нового функционала, а на последних этапах иногда нереально сложно, и всегда займет намного больше времени.
However, Hoare was not saying, «concern about application performance during the early stages of an application's development is evil.» He specifically said premature optimization; and optimization meant something considerably different back in the days when he made that statement. Back then, «optimization» often consisted of activities such as counting cycles and instructions in assembly language code. This is not the type of coding you want to do during initial program design, when the code base is rather fluid.
И сразу все заиграло другими красками.
Тоже "по молодости" ставил на performance-first, это казалось крутым. Но это требовало очень точного и зафиксированного описания задачи ("мамой клянусь, не поменяется до релиза ничего").
Вот только в реальной жизни это не так.
Единственное место, где реально такой подход применять, если хочется, — это всякие соревновательные контесты, типа отечественного highload cup или всякие примеры олимпиадного программирования.
В реальной жизни все очень быстро меняется, либо остаётся недосказанность и отсутствие конкретики в неучтенных краевых случаях. А чем больше система (и задание на нее), тем выше шанс не заметить/не учесть что-то.
И, если сразу делать эффективное решение, то потом будет очень больно его переделывать.
Так что много лет уже следую принципу:
- Сначала сделать по т.з.;
- Потом сделать корректно (тесты, ручные тесты, выдача early bird, и любые другие способы проверить логику и реализацию с обратной связью. Тут может всплыть огромное количество нюансов, которые сразу и правятся);
// Тут может произойти релиз, если нужно минимизировать time-to-market; - Потом сделать быстро там, где есть проблема. А для этого нужны бенчмарки решения целиком, чтобы видеть бутылочные горлышки;
// Вот тут уже релизим, если ещё нет.
Есть вариант, когда ты пишешь систему, в которой в Т.З. прописаны серьезные ограничения на производительность (не ниже ХХХ) — системы видеонаблюдения, торговля на бирже, какие-нибудь АРМ комплексы (real time и near real time). Тогда в любом случае приемка будет осуществляться в случае попадания в ожидания Заказчика проекта.
В случае обычных веб-приложений немного попроще — потому что тормозит, ну, да ладно — народ утрется. Хотя потери клиентской базы из-за того, то сайт долго открывался, тоже могут быть весьма существенны.
И это вовсе не отменяет пп1-2-3, просто возможность ускорения нужно закладывать на начальном этапе проектирования в случае, если это прям критикал… Либо делать несколько итераций продукта (с потенциальным полным переписыванием на каждой итерации)…
Например, код должен укладываться в 100мс на 99м перцентиле. Ок. И если он работает за 110мс — это не выполненное задание.
Но после первого релиза можно, при наличии времени, оптимизировать до 50мс, и тем самым немного поднять метрики продукта. (Пример из более-менее реальной жизни).
Закладывание возможности ускорения (как и будущие итерации) я воспринимаю как закладывание возможности дальнейшего развития и доработок. Если код уже написан так плохо, что его уже нельзя поддерживать уже на таких ранних этапах, то тут все плохо, как бы быстро/медленно решение не работало.
А возможность развития — это ведь вообще основополагающее требование к коду (если речь опять же не про «олимпиадное программирование»).
Насчет ускорения JS: разве он стал быстрее не потому, что больше ресурсов стало доступно JIT-компилятору (когда у вас одно ядро работает, а 2 других ядра профайлят выполнение и перекомпилируют код) — разве мы можем отправить эти имплементации на железо 20 летней давности, где C/C++ был незаменим?
Производительность главнее всего