Подтвердить что ты не робот

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

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

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

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

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

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

Этот вопрос беспокоил меня с недели, и у меня пока нет ответа. Каково ваше отношение к этому?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

Ответ 5

Я должен ответить всем своим сердцем.

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

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

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

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

Ответ 6

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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

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

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

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

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

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