13thДолжно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Если бы можно было бы группировать, я бы всё отправил один раз в секунду, и это заняло бы 10ms.
Каждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Поэтому никакого распараллеливания отправки тоже быть не может. Клиенты и так работают параллельно.В таком случае, все твои компоненты завязаны на производительности друг друга и, в буквальном смысле, осуществляют синхронную обработку сообщений ожидая, пока самый тормозной компоненты обработает сообщение. Занафига?

13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. Но пересылать группами по 100 штук - уже без варика. Так же нельзя менять порядок котировок - по понятным причинам.Пойди от обратного - используй для каждого компоненты свой memory-mapped файл, чтобы данные представляли из себя унифицированную структуру меняющегося в размере кольца сообщений, где есть начало кольца, задающееся диспетчерской программой, его размер и конец кольца - последнее сообщение, прочитанное получателем. Всё это прекрасно будет разруливаться без всякой синхронизации одними лишь командами барьеров памяти. Алгоритм работы кольца сам додумаешь.

13thПоверь, всё уже уменьшено и оптимизирована до предела. И число GDI не уменьшить. И USER. Мне нужен быстрый IPC, а не рассказы, как у меня всё неэффективно.Не верю! Нет предела совершенству!!!
Еще можно написать какой-нибудь драйвер с колбэками, который будет плеваться сообщениями. ;)