Любые документы, в которых исследуются проблемы производительности и стратегии оптимизации, доступные для COM-приложений на основе C++?

Весьма вероятно, что С++ не виноват - скорее всего, это что-то вроде сортировки, которая срабатывает и занимает большую часть времени. Не забывайте, что у вас будет сортировка и для внутрипроцессных серверов — на случай, если модели потоковой передачи потребителя и сервера несовместимы. Также вы можете потратить много времени на синхронизацию в некоторых случаях.

Избавление от маршалинга или его оптимизация (есть такая вещь, как «беспоточный маршаллер», которого я сам не понимаю, но выглядит многообещающе с точки зрения повышения производительности) даст вам огромный импульс — каждый вызов будет идти напрямую, а не тонна проводки. Опять же, настройка синхронизации (сделав ее мелкозернистой и минимальной) также может повысить производительность.

Однажды у нас была серьезная проблема с производительностью в компоненте STA — вызовы из разных потребительских потоков проходили через прокси и сериализовались. Поскольку каждый вызов блокировался на длительный период времени (ожидая, пока бэкэнд выполнит сложную обработку данных), все остальные потоки просто висели в ожидании своей очереди — сервер обслуживал по одному запросу за раз. Мы изменили дизайн вызова — теперь он просто «отправляет» запрос, а событие COM срабатывает после завершения обработки. Это решило проблему — теперь «ожидание» было вынесено за пределы вызова, поэтому COM-синхронизация не блокировала слишком долго все потоки и не препятствовала параллелизму. Это не является чем-то специфичным для какого-либо языка — просто то, как работает параллелизм COM. Вы находите такие проблемы, тщательно регистрируя все звонки и просматривая журналы.

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

COM независим от языка/платформы по своему замыслу.
Таким образом, поиск методов оптимизации, специфичных для C++, немного выпадает из контекста. Для платформы COM и COM-серверов клиент C++ — это всего лишь один из клиентов, только работающий в более оптимизированном машинном коде.

COM — это протокол/архитектура для взаимодействия/коммуникации между сервером и клиентом.
Таким образом, минимизация самого доступа к серверу будет важнее, чем оптимизация операции доступа к серверу.

С другой стороны, некоторые COM-серверы предоставляют низкоуровневые интерфейсы, доступные только клиентам C/C++. Думаю, лучшим примером является элемент управления IE WebBrowser. Для этих COM-серверов использование C++ может привести к значительному повышению производительности. Но пакет MS Office AFAIK не предоставляет интерфейсы такого низкого уровня.

То есть весьма вероятно, что независимо от того, создаете ли вы модуль доступа к пакету MS Office на C++, C# или VB6, затраты на обработку, специфичные для COM (вызов методов интерфейса COM-сервера и получение результатов), могут быть измерены одинаково.

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

Просто проверяю очевидное: COM везде использует BSTR, которые содержат WCHAR[]. Используют ли ваши приложения WCHAR или вы переключаетесь между char и WCHAR при каждом вызове?