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

Question

Желательно ли сосредоточиться на разработке компонента или архитектуры программного обеспечения с учетом производительности? Я имею в виду, насколько готов проект / архитектура к использованию в среде с высокой производительностью?

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

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

Примечание: ни в одном из перечисленных выше случаев я не пытаюсь настроить производительность программного обеспечения перед тем, как столкнуться с проблемами производительности. Если перефразировать вопрос, должен ли дизайн программного обеспечения ориентироваться на производительность?

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

Этот вопрос беспокоит меня уже неделю, и у меня пока нет ответа. Что вы думаете об этом?

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

Я должен второй ответ JK всем сердцем.

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

Не делайте оптимизацию заранее. Но ARCHITECTURE имеет огромное влияние на потенциальную производительность системы.

Я предлагаю ознакомиться со следующей книгой: Release It !: Разработка и развертывание готового программного обеспечения

Answer 8

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

Хотя цитата Кнута TRVTH , все сводится к требованиям. Является ли масштабируемость одним из них? Какова ожидаемая нагрузка? Если ваш ответ «Я не знаю», спросите.

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

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

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

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

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

Answer 9

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

Answer 10

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

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