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

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

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

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

Итак, было бы здорово, если бы вы, ребята, могли помочь мне выкопать несколько важных документов из экскаваторов в Интернете.
Кроме того, (поскольку моя работа настолько очевидна), все же стоит написать свой опыт в качестве документа?

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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