Как создать быстрое программное обеспечение?
Неверный способ
Если вы программист, вы, вероятно, знакомы с этой цитатой Кнута:
Преждевременная оптимизация — корень всех зол.
Многие программисты считают, что это нормальный способ разработки продуктов:
Некоторые также думают, что производительность — это просто еще одна функция, которую можно добавить позже:
Я считаю эту логику ошибочной. Если ваша программа все еще является прототипом и выполняет, например, 1% (20%, 50%, 90%) того, что она должна делать, и она уже работает медленно, то она будет еще более медленной после того, как вы ее закончите, разве нет? Если вы заставите ее делать больше, почему он должна стать быстрее?
Если кто-то говорит:
Мы создаем программы сначала правильными, а потом — производительными. Мы оптимизируем их после того, как они будут реализованы.
На самом деле это означает: производительность в основном останется прежней, если только эти люди не найдут простые способы, которые позволят им сделать программу быстрой, не меняя слишком много из того, что они уже создали.
И у меня с этим проблемы. Это более или менее равносильно тому, что финальная производительность остается на волю случая. ЕСЛИ вам удастся найти какое-то огромное узкое место в производительности и если его изменение не повлияет на архитектуру, вы МОЖЕТЕ получить некоторое ускорение, да. Но никто не может вам этого гарантировать. Это ставка. Вы либо получите некое ускорение, либо нет. По сути, вы принимаете любую производительность с небольшим шансом на небольшое улучшение. И вы назовете это хорошей инженерией?
Может показаться, что в истории полно программ, которые после выпуска стали работать быстрее. Всего несколько примеров всплывают в памяти: Chrome известен как пионер многих улучшений скорости JS. Компиляторы Kotlin и Rust получили много ускорений. VS Code / Atom в конечном итоге стали более быстрыми версиями своих оригинальных прототипов Electron. И я не говорю, что невозможно ускорить программы после выпуска. Я говорю, что эти улучшения случайны. Им просто повезло. Они могли никогда не случиться так легко, как раньше.
Верный способ
Мой вывод таков: если вы хотите создать действительно быструю программу, с самого начала обращайте внимание на производительность. Никогда не бывает рано начинать измерять и работать над эффективностью. Ваши прототипы должны работать быстро, намного быстрее, чем окончательная программа.
Во-первых, если вы начнете с быстрой программы, гораздо легче предотвратить снижение производительности, чем начать с медленной программы и надеяться, что вы найдете простой способ ее ускорить.
Затем, если вы действительно серьезно относитесь к результативности вашей окончательной программы, каждое решение должно приниматься с учетом производительности. Платформа, язык, архитектура, фреймворк, пользовательский интерфейс, бизнес-задачи, бизнес-модель. Можно ли их сделать быстрыми? Можем ли мы использовать язык X или фреймворк Y, можно ли их сделать быстрыми? Можем ли мы сделать эту функцию быстрой? Если нет, то чем ее заменить? Как сделать интерфейс быстрым? Как сделать так, чтобы он появлялся быстро? Подобные решения легко принять на раннем этапе, но невозможно изменить позже. Например, за последние годы скорость JavaScript впечатляла, но он все еще не может быть таким же быстрым, как C ++ или даже Java. Если бы вы поставили перед собой цель создать быстрый язык, в итоге вы бы создали другой язык!
Позвольте мне сформулировать это так:
«Преждевременная оптимизация — корень всех зол» — это корень всех зол.
Автор: T-800
