[Программирование, Отладка, Управление разработкой] Производительность главнее всего (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Как создать быстрое программное обеспечение?
Неверный способ
Если вы программист, вы, вероятно, знакомы с этой цитатой Кнута:
Преждевременная оптимизация — корень всех зол.
Многие программисты считают, что это нормальный способ разработки продуктов:
Некоторые также думают, что производительность — это просто еще одна функция, которую можно добавить позже:
Я считаю эту логику ошибочной. Если ваша программа все еще является прототипом и выполняет, например, 1% (20%, 50%, 90%) того, что она должна делать, и она уже работает медленно, то она будет еще более медленной после того, как вы ее закончите, разве нет? Если вы заставите ее делать больше, почему он должна стать быстрее?
Если кто-то говорит:
Мы создаем программы сначала правильными, а потом — производительными. Мы оптимизируем их после того, как они будут реализованы.
На самом деле это означает: производительность в основном останется прежней, если только эти люди не найдут простые способы, которые позволят им сделать программу быстрой, не меняя слишком много из того, что они уже создали.
И у меня с этим проблемы. Это более или менее равносильно тому, что финальная производительность остается на волю случая. ЕСЛИ вам удастся найти какое-то огромное узкое место в производительности и если его изменение не повлияет на архитектуру, вы МОЖЕТЕ получить некоторое ускорение, да. Но никто не может вам этого гарантировать. Это ставка. Вы либо получите некое ускорение, либо нет. По сути, вы принимаете любую производительность с небольшим шансом на небольшое улучшение. И вы назовете это хорошей инженерией?
Может показаться, что в истории полно программ, которые после выпуска стали работать быстрее. Всего несколько примеров всплывают в памяти: Chrome известен как пионер многих улучшений скорости JS. Компиляторы Kotlin и Rust получили много ускорений. VS Code / Atom в конечном итоге стали более быстрыми версиями своих оригинальных прототипов Electron. И я не говорю, что невозможно ускорить программы после выпуска. Я говорю, что эти улучшения случайны. Им просто повезло. Они могли никогда не случиться так легко, как раньше.
Верный способ
Мой вывод таков: если вы хотите создать действительно быструю программу, с самого начала обращайте внимание на производительность. Никогда не бывает рано начинать измерять и работать над эффективностью. Ваши прототипы должны работать быстро, намного быстрее, чем окончательная программа.
Во-первых, если вы начнете с быстрой программы, гораздо легче предотвратить снижение производительности, чем начать с медленной программы и надеяться, что вы найдете простой способ ее ускорить.
Затем, если вы действительно серьезно относитесь к результативности вашей окончательной программы, каждое решение должно приниматься с учетом производительности. Платформа, язык, архитектура, фреймворк, пользовательский интерфейс, бизнес-задачи, бизнес-модель. Можно ли их сделать быстрыми? Можем ли мы использовать язык X или фреймворк Y, можно ли их сделать быстрыми? Можем ли мы сделать эту функцию быстрой? Если нет, то чем ее заменить? Как сделать интерфейс быстрым? Как сделать так, чтобы он появлялся быстро? Подобные решения легко принять на раннем этапе, но невозможно изменить позже. Например, за последние годы скорость JavaScript впечатляла, но он все еще не может быть таким же быстрым, как C ++ или даже Java. Если бы вы поставили перед собой цель создать быстрый язык, в итоге вы бы создали другой язык!
Позвольте мне сформулировать это так:
«Преждевременная оптимизация — корень всех зол» — это корень всех зол.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Nikita Prokopov
===========Похожие новости:
- [Разработка веб-сайтов, JavaScript, Программирование, TypeScript] Совет #1 по ознакомлению с новыми кодовыми базами JavaScript (перевод)
- [Open source, Python, Программирование] Все важные фичи и изменения в Python 3.10 (перевод)
- [Разработка веб-сайтов, CSS, Программирование, HTML] Вы можете создавать эти элементы, не используя JavaScript (перевод)
- [Программирование, Анализ и проектирование систем, Проектирование и рефакторинг, IT-стандарты] Хороший, плохой, злой комментарий
- [Программирование, Rust] Макросы в Rust. macro_rules
- [Python, Программирование, Учебный процесс в IT, Data Engineering] Из филолога в Python-разработчики: как переучиться и чего ждать от новой профессии
- [Программирование микроконтроллеров, Интернет вещей] 10 плат для начала разработки IoT в 2021 (перевод)
- [Python, JavaScript, Программирование, HTML] Python & EEL. Делаем просто на Python’е и красиво на JS
- [Высокая производительность, Компиляторы, Процессоры, Криптовалюты, Суперкомпьютеры] Мультиклеточная архитектура: тесты и развитие
- [Управление разработкой, Управление продуктом, Бизнес-модели, Производство и разработка электроники, IT-компании] Во все тяжкие: как Intel потеряла хватку и решила вернуть былое величие
Теги для поиска: #_programmirovanie (Программирование), #_otladka (Отладка), #_upravlenie_razrabotkoj (Управление разработкой), #_proizvoditelnost (производительность), #_blog_kompanii_npp_itelma (
Блог компании НПП ИТЭЛМА
), #_programmirovanie (
Программирование
), #_otladka (
Отладка
), #_upravlenie_razrabotkoj (
Управление разработкой
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 10:25
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Как создать быстрое программное обеспечение? Неверный способ Если вы программист, вы, вероятно, знакомы с этой цитатой Кнута: Преждевременная оптимизация — корень всех зол.
Многие программисты считают, что это нормальный способ разработки продуктов:  Некоторые также думают, что производительность — это просто еще одна функция, которую можно добавить позже:  Я считаю эту логику ошибочной. Если ваша программа все еще является прототипом и выполняет, например, 1% (20%, 50%, 90%) того, что она должна делать, и она уже работает медленно, то она будет еще более медленной после того, как вы ее закончите, разве нет? Если вы заставите ее делать больше, почему он должна стать быстрее? Если кто-то говорит: Мы создаем программы сначала правильными, а потом — производительными. Мы оптимизируем их после того, как они будут реализованы.
На самом деле это означает: производительность в основном останется прежней, если только эти люди не найдут простые способы, которые позволят им сделать программу быстрой, не меняя слишком много из того, что они уже создали. И у меня с этим проблемы. Это более или менее равносильно тому, что финальная производительность остается на волю случая. ЕСЛИ вам удастся найти какое-то огромное узкое место в производительности и если его изменение не повлияет на архитектуру, вы МОЖЕТЕ получить некоторое ускорение, да. Но никто не может вам этого гарантировать. Это ставка. Вы либо получите некое ускорение, либо нет. По сути, вы принимаете любую производительность с небольшим шансом на небольшое улучшение. И вы назовете это хорошей инженерией? Может показаться, что в истории полно программ, которые после выпуска стали работать быстрее. Всего несколько примеров всплывают в памяти: Chrome известен как пионер многих улучшений скорости JS. Компиляторы Kotlin и Rust получили много ускорений. VS Code / Atom в конечном итоге стали более быстрыми версиями своих оригинальных прототипов Electron. И я не говорю, что невозможно ускорить программы после выпуска. Я говорю, что эти улучшения случайны. Им просто повезло. Они могли никогда не случиться так легко, как раньше. Верный способ Мой вывод таков: если вы хотите создать действительно быструю программу, с самого начала обращайте внимание на производительность. Никогда не бывает рано начинать измерять и работать над эффективностью. Ваши прототипы должны работать быстро, намного быстрее, чем окончательная программа. Во-первых, если вы начнете с быстрой программы, гораздо легче предотвратить снижение производительности, чем начать с медленной программы и надеяться, что вы найдете простой способ ее ускорить. Затем, если вы действительно серьезно относитесь к результативности вашей окончательной программы, каждое решение должно приниматься с учетом производительности. Платформа, язык, архитектура, фреймворк, пользовательский интерфейс, бизнес-задачи, бизнес-модель. Можно ли их сделать быстрыми? Можем ли мы использовать язык X или фреймворк Y, можно ли их сделать быстрыми? Можем ли мы сделать эту функцию быстрой? Если нет, то чем ее заменить? Как сделать интерфейс быстрым? Как сделать так, чтобы он появлялся быстро? Подобные решения легко принять на раннем этапе, но невозможно изменить позже. Например, за последние годы скорость JavaScript впечатляла, но он все еще не может быть таким же быстрым, как C ++ или даже Java. Если бы вы поставили перед собой цель создать быстрый язык, в итоге вы бы создали другой язык! Позвольте мне сформулировать это так: «Преждевременная оптимизация — корень всех зол» — это корень всех зол.
=========== Источник: habr.com =========== =========== Автор оригинала: Nikita Prokopov ===========Похожие новости:
Блог компании НПП ИТЭЛМА ), #_programmirovanie ( Программирование ), #_otladka ( Отладка ), #_upravlenie_razrabotkoj ( Управление разработкой ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 10:25
Часовой пояс: UTC + 5