Повышение производительности в системах реального времени

Для общей работы системы в реальном времени классическое правило состоит в том, чтобы преследовать изменчивость и уничтожать ее. Реальное жесткое реальное время означает использование статических расписаний, оптимизированных операционных систем, эффективных драйверов устройств и жестких приоритетов. Никакие динамические или адаптивные вещи невозможны, если вы действительно хотите, чтобы вычисление X закончилось в пределах известного ограниченного по времени T.

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

Вы уже упомянули архитектуру, управляемую событиями, я бы посоветовал вам взглянуть на поэтапную архитектуру, управляемую событиями (SEDA).

Стадия — это, по сути, очередь для событий и функция для работы с событием. «Нетрадиционная» особенность этой архитектуры заключается в том, что каждый этап может выполняться в своем собственном потоке, а функциям обычно требуется асинхронный ввод-вывод и т. д. Организация программ таким образом поначалу неудобна, но позволяет использовать все виды магии, например QoS, измененное расписание и т. д.

См. диссертацию Уэлша в Беркли и его веб-сайт. Вы также можете ознакомиться с проектом Майнора Гордона (из Кембриджа, Великобритания) под названием yield. У него были очень хорошие результаты. Сначала может показаться, что проект ориентирован на Python, но его можно использовать и для чистого C++.

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

То, что внутри этого цикла, рассчитывается с тем же выходом, что и вне цикла. В качестве основного примера:

for(int i=0;i< x/2; i++)
  //do something

Здесь вы можете безопасно взять x/2 и вычислить его перед циклом и повторно использовать это значение (теперь современные компиляторы заботятся об этих тривиальных оптимизациях)

Чтобы увидеть последствия этого простого правила, я могу привести пример с запросами к базе данных. Чтобы избежать ВНУТРЕННЕГО СОЕДИНЕНИЯ двух таблиц, чтобы получить часто повторяющееся поле, вы можете нарушить правила нормализации и дублировать его в таблице, относящейся к той, которая имеет значение. Это позволяет избежать повторяющейся обработки объединения таблиц и может освободить параллелизацию, поскольку только одна из таблиц должна быть заблокирована для транзакций. Пример:

Запросам таблицы клиентов периодически требуется скидка клиента, но скидка сохраняется в таблице типов клиентов.

Не «чините» ничего, если вы точно не знаете, что это «сломано».

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