Следует ли разрабатывать программное обеспечение с учетом производительности?

Когда я пишу это, два человека уже ответили цитатой Кнута о преждевременной оптимизации. Я думаю, что это несколько вводит в заблуждение. Идея, лежащая в основе этого, и многих советов по этой теме, мне кажется, заключается в том, что программа представляет собой набор алгоритмов, и если она недостаточно эффективна, мы можем определить, какой из алгоритмов слишком медленный, и заменить его чем-нибудь. лучше.

Подобные вещи игнорируют взаимосвязанность программы. Все алгоритмы скрыты за некоторыми API. Хотя «видение» состоит в том, что алгоритм, лежащий в основе API, непрозрачен и взаимозаменяем с другим, он игнорирует ограничения, накладываемые API на его вызывающую сторону. Я довольно много занимался сетевым программированием, и там легко написать неэффективное программное обеспечение, создав API-интерфейсы, которые просто не могут работать эффективно, так что же вы будете делать, если вам нужно внести фундаментальные изменения в API, который используется повсюду? (В сетевом программировании API, который требует, чтобы вызывающий объект создал полное сообщение в памяти, легче спроектировать и реализовать, чем, например, тот, который позволяет передавать данные в потоковом режиме.)

Так что не поддавайтесь упрощенным и содержательным цитатам. Вы не должны беспокоиться о мелочах (и особенно не беспокоиться о вещах, которые делали люди в 70-х; компиляторы теперь намного умнее), но полностью игнорировать проблемы с производительностью с отношением «Мы всегда можем профилировать и улучшить вещи позже. при необходимости »может завести вас в тупик, где вам придется провести значительную повторную реализацию.

Да, и я бы также посоветовал не «проектировать с учетом расширяемости». Сделайте самое простое, что работает, и если позже вы обнаружите, что обобщение чего-то, что у вас есть, упрощает или упрощает задачу, сделайте это тогда. По моему опыту, переход к ненужному общему дизайну просто приводит к более сложному в использовании компоненту, который часто не очень расширяемый, потому что первоначальный дизайн не мог фактически предвидеть, какие вещи должен делать компонент в общем случае. и как.

При разработке проекта необходимо уравновесить возможность расширения, ремонтопригодность, производительность, время доставки и многое другое.

Я пытаюсь разработать пакет + высокоуровневые диаграммы для расширяемости, а затем разработать низкоуровневые диаграммы для повышения производительности.

Я должен от всей души поддержать ответ JK.

Цитата Кнута несколько неприменима в реальной жизни за пределами небольшой области проблем, не связанных с архитектурой.

Например, мне недавно пришлось потратить 3-4 месяца на перестройку с нуля довольно сложной системы, потому что исходный дизайн предполагал, что 100% данных будут загружены в один блок из базы данных. И это было нормально в течение 3 лет, пока набор данных не вырастет примерно в 100 раз по сравнению с тем, что ожидал первоначальный разработчик, и система не начала чередоваться между простым нехваткой памяти при использовании 2G или ужасным сбоем.

Теперь решение было концептуально простым - разрешить извлечение данных из БД партиями. Это сработало с умом. Но то, что могло бы быть лишней парой недель работы на первоначальном этапе проектирования, если бы они позаботились о том, чтобы производительность превратилась в трехмесячное испытание, потому что каждая маленькая функция, объект и API, а также общая архитектура были явно написаны, чтобы предполагать «100% данные есть ".

В общем, любая ситуация, когда объем данных является проблемой для производительности, а фрагменты данных являются основным возможным решением, такое разбиение ДОЛЖНО быть разработано заранее.

Я бы посоветовал придерживаться хороших объектно-ориентированных принципов, если вы с самого начала не знаете, что каждая небольшая часть производительности будет иметь значение.

Большой прирост производительности обычно достигается за счет алгоритмической оптимизации, а не реструктуризации архитектуры (если архитектура следует нормальным передовым практикам). Прирост производительности, который вы получаете от выбора более сложной для работы конструкции, чаще всего не имеет значения во всех средах, кроме наиболее требовательных к производительности, поэтому, если абсолютная максимальная производительность не является требованием с самого начала, используйте хороший объектно-ориентированный подход.

Я бы сказал, что в этом разница между опытным программистом и новичком в программном обеспечении.

Опытный инженер-программист всегда должен помнить о проблемах производительности своего проекта.

Пример: когда у вас есть алгоритм с поведением производительности O (n ^ 3) внутри вашего модуля с возможным увеличением n, может возникнуть ситуация, когда ваш модуль станет очень медленным в обстоятельствах.

Конечно, есть много отличий. Когда у вас есть O (n ^ 3) в массиве в памяти, это может быть менее проблематично, как O (n ^ 2) для операции с диском.

Итак, опыт важен, чтобы подумать об этих вещах и решить, где нужно изменить дизайн или где более поздняя настройка может ускорить работу без проблем.

Программное обеспечение с хорошей архитектурой, которое следует передовым практикам ООП, широко использует шаблоны проектирования, является или в принципе должно быть хорошо обслуживаемым. В настоящее время низкоуровневые оптимизации редко имеют реальную роль, ЦП и ресурсы слишком велики.

Просто код, который можно использовать повторно, поддерживать и масштабировать. Дальнейшие реальные потребности в оптимизации на низком уровне будут легко реализованы в такой хорошей среде. Только тогда, когда это действительно необходимо, только когда действительно наступает момент заняться этой проблемой.

Вы всегда должны стремиться к эффективности, а не к неэффективности, но не за счет ремонтопригодности. Итак, да, вам следует попытаться разработать для повышения эффективности, но остерегайтесь преждевременной оптимизации. Любимая цитата Дональда Кнута:

«Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - корень всех зол».

Я думаю, что почти в зависимости от обстоятельств вам действительно нужно принимать во внимание ваши требования. Если одно из самых приоритетных требований - «должна быть в состоянии поддерживать какой-то сумасшедший уровень пропускной способности / производительности», то вы были бы сумасшедшими, если бы не спланировали и не спроектировали это заранее при выборе общей архитектуры и технологий.

Мне интересно, что только Микаэль Ауно упомянул слово «требование».

Цитата Кнута - TRVTH, но все сводится к требованиям. Масштабируемость - одна из них? Какая ожидаемая нагрузка? Если ваш ответ "Я не знаю", спросите.

Если это требования, добавьте нагрузочное тестирование к своим приемочным испытаниям.

Вы по-прежнему хотите, чтобы дизайн был удобен в обслуживании. Отложите соображения производительности на последний ответственный момент, затем профилируйте - не угадайте . Микрооптимизация - пустая трата денег компании.

Иногда ответственный момент наступает довольно рано; Я не собираюсь разрабатывать корпоративную CRM-систему, в которой все данные хранятся в виде файлов XML на диске. Я собираюсь абстрагироваться от уровня сохраняемости.

В конце концов, комментарий Колибри верен - ответ (как обычно): «это зависит от обстоятельств».

РЕДАКТИРОВАТЬ: при повторном чтении, боюсь, я нарушил ограничение OP «Пожалуйста, не отвечайте мне, говоря, что все зависит от среды, в которой предполагается запускать программное обеспечение». Однако я стою за своим ответом. Если (когда) требования меняются, простой дизайн, как правило, легче изменить. Неизложенное предположение состоит в том, что мы заранее знаем, как требования изменятся. Запрос может быть «масштабировать на порядок» или «разрешить перемещение клиента между организациями». Создание архитектуры для первого может затруднить реализацию второго.

Не стоит заранее оптимизировать. Но АРХИТЕКТУРА оказывает огромное влияние на потенциальную производительность системы.

Предлагаю прочитать следующую книгу: Выпустить !: Дизайн и развертывание Готовое программное обеспечение