Программное обеспечение должно быть разработано с производительностью в памяти?
это сработало для меня:
<binding name="uploadFilesBasicHttpBinding" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" maxBufferPoolSize="2147483647" receiveTimeout="00:10:10" sendTimeout="00:10:00" openTimeout="00:10:00" closeTimeout="00:10:00">
<readerQuotas maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxDepth="2147483647" maxNameTableCharCount="2147483647" maxStringContentLength="2147483647"/>
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName"/>
</security>
</binding>
10 ответов
Когда я пишу это, два человека уже ответили цитатой Кнута о преждевременной оптимизации. Я думаю, это несколько вводит в заблуждение. Мышление, стоящее за этим, и за многими советами по этой теме мне кажется, что программа - это совокупность алгоритмов, и если она недостаточно эффективна, мы можем определить, какой из алгоритмов слишком медленный, и заменить его чем-то лучшим.
Подобные вещи игнорируют взаимосвязанность программы. Все алгоритмы скрыты за некоторыми 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 «Пожалуйста, не отвечайте мне, говоря, что все зависит от среды, в которой предполагается запускать программное обеспечение». Но я стою за своим ответом. Если (когда) требования меняются, простой дизайн, как правило, легче изменить. Неустановленное предположение состоит в том, что мы заранее знаем, как требования изменятся. Запрос может быть «масштабировать на порядок» или «разрешить перемещение клиента между организациями». Создание архитектуры для первого может затруднить реализацию второго.
комментарий правильный - ответ (как обычно) - «это зависит».РЕДАКТИРОВАТЬ: при повторном чтении, боюсь, я нарушил ограничение OP «Пожалуйста, не отвечайте мне, говоря, что все зависит от среда, в которой предполагается запускать программное обеспечение ". Однако я стою за своим ответом. Если (когда) требования меняются, простой дизайн, как правило, легче изменить. Неизложенное предположение состоит в том, что мы заранее знаем , как требования изменятся. Запрос может быть «масштабировать на порядок» или «разрешить перемещение клиента между организациями». Создание архитектуры для первого может затруднить реализацию второго.
комментарий правильный - ответ (как обычно) - «это зависит».РЕДАКТИРОВАТЬ: при повторном чтении, боюсь, я нарушил ограничение OP «Пожалуйста, не отвечайте мне, говоря, что все зависит от среда, в которой предполагается запускать программное обеспечение ". Но я стою за своим ответом. Если (когда) требования меняются, простой дизайн, как правило, легче изменить. Неизложенное предположение состоит в том, что мы заранее знаем , как требования изменятся. Запрос может быть «масштабировать на порядок» или «разрешить перемещение клиента между организациями». Создание архитектуры для первого может затруднить реализацию второго.
s ограничение «Пожалуйста, не отвечайте мне, говоря, что все зависит от среды, в которой предполагается запускать программное обеспечение». Но я стою за своим ответом. Если (когда) требования меняются, простой дизайн, как правило, легче изменить. Неизложенное предположение состоит в том, что мы заранее знаем , как требования изменятся. Запрос может быть «масштабировать на порядок» или «разрешить перемещение клиента между организациями». Создание архитектуры для первого может затруднить реализацию второго. s ограничение «Пожалуйста, не отвечайте мне, говоря, что все зависит от среды, в которой предполагается запускать программное обеспечение». Но я стою за своим ответом. Если (когда) требования меняются, простой дизайн, как правило, легче изменить. Неизложенное предположение состоит в том, что мы заранее знаем , как требования изменятся. Запрос может быть «масштабировать на порядок» или «разрешить перемещение клиента между организациями». Создание архитектуры для первого может затруднить реализацию второго. Неизложенное предположение состоит в том, что мы заранее знаем , как требования изменятся. Запрос может быть «масштабировать на порядок» или «разрешить перемещение клиента между организациями». Создание архитектуры для первого может затруднить реализацию второго. Неустановленное предположение состоит в том, что мы заранее знаем, как требования изменятся. Запрос может быть «масштабировать на порядок» или «разрешить перемещение клиента между организациями». Создание архитектуры для первого может затруднить реализацию второго.