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

Question

Предостережение: я не уверен, можно ли это считать правильным вопросом программирования SO!

При работе с MS Office Suite я столкнулся с серьезными потерями производительности, главным образом из-замиллионы звонков COM, которые я делаю для обработки документов.Часть проблемы была исправлена ​​с помощью OOXML SDK вместо API нативного приложения.Однако сам OOXML SDK выполняет COM-вызовы, и это замедляет работу (да, я должным образом запустил встроенный анализатор производительности Visual Studio и BoundsChecker и убедился, что алгоритмы являются лучшими, которые мы можем использовать повсюду).Я полагал, что уровень кэширования значительно ускоряет (иногда сокращая время выполнения на четверть) (но, очевидно, ускорение варьируется в зависимости от моего шаблона доступа, который, в свою очередь, регулируется структурой содержимого документа).

Учитывая тот факт, что COM и C ++ существовали так долго, я удивлен, увидев, что так мало материала по оптимизации COM-приложений на основе C ++.(Быстрый поиск в Google должен быть достаточным, чтобы доказать мою точку зрения, хотя я не возражаю против того, чтобы оказаться неправым!)документы из драги в интернете.

Кроме того, (поскольку моя работа настолько очевидна), стоит ли все еще описывать мой опыт работы в качестве бумаги?

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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