Эффективность шаблонов проектирования

Шаблоны проектирования существуют для того, чтобы помочь вам понять, как разрабатывать программное обеспечение или улучшить его гибкость. То, как вы реализуете паттерн, определяет, какой штраф за производительность (или выгоду) вы увидите от его использования.

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

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

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

Самый конкретный совет: примените это в своем приложении и посмотрите, насколько это действительно влияет.

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

Один термин, который может помочь вам получить более точные результаты, - это «язык шаблонов». Это набор шаблонов, которые для какой-то цели подходят друг другу. Если у вас есть более конкретная цель - высокая производительность, кто-то, возможно, проложил путь через шаблоны для вашего домена, например: язык шаблонов для параллельного программного обеспечения . Вот еще одна замечательная коллекция шаблонов параллельного программирования от UIUC, очага работы с шаблонами.

Ребята из ACE / TAO имеют множество статей о высокопроизводительных сетевых шаблонах с использованием C ++

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

Правило 80/20 гласит, что 80 процентов времени выполнения вашей программы будет потрачено на выполнение 20 процентов ее кода. Когда ваша программа является красивой и модульной, ее легко добавить в профилировщик и посмотреть, какой именно компонент можно настроить / оптимизировать или где имеет смысл использовать менее гибкий дизайн для повышения производительности. Несмотря на то, что изначально разнесенный дизайн значительно упрощает поиск «горячих точек» производительности.

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

Для C++ я определенно рекомендую прочитать книгу Скотта Мейерса "Эффективный C++" и серию книг "Более эффективный C++", которые сами по себе действительно раскрывают многие идиомы по написанию высокопроизводительного кода.

Вы можете прочитать записи Херба Саттера в разделе «Эффективный параллелизм» "для вещей, связанных с шаблонами многопоточности и параллелизма, и их влияния на производительность.

http://herbsutter.com/

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

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

Что делает ваше приложение?

Если ваше приложение на C++ и написано с умом, есть шанс, что ваш код будет работать ослепительно быстро на современном оборудовании, пока ему не придется ждать ввода-вывода. Исключением может быть что-то вроде анализа изображений в реальном времени, который очень требователен к процессору.

Если производительность является проблемой, вы действительно имеете в виду производительность ввода-вывода? (диск, БД, сеть и т.д.)

Существуют "паттерны", которые позволяют вашему приложению работать даже при частом ожидании ввода-вывода (асинхронные обратные вызовы и т.д.)

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

Помните старую поговорку "Вы можете иметь это хорошо, быстро и дешево, выберите два"
. Паттерны проектирования направлены на хорошее. Необходима хорошая основа, чтобы код был точным и удобным для сопровождения.
Если производительность является проблемой, то проведите сравнительный анализ, а затем оптимизируйте те участки, которые вызывают проблемы. Во многих случаях производительность - это просто вопрос выбора правильного алгоритма, но это может означать, что вам нужно вырваться в ужасно оптимизированный код для тех 10%, которые занимают 90% времени. Просто убедитесь, что вы прокомментировали S^^^T из этого.