2015-09-17 4 views
-1

Пожалуйста, можете пролить свет на это.Ускорение вызовов Com Interop с помощью неуправляемого C++ на объекте interop

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

inline Microsoft :: Office :: Interop :: Outlook :: _ Application^OutlookApp() { return dynamic_cast (HostApplication); }

Что бы я хотел сделать, это передать выше возвращенный объект outlook из этой подпрограммы, возможно, с манипуляцией или привязкой к неуправляемой подпрограмме C++, а затем манипулировать ею в качестве основного объекта native com, чтобы получить скорость неуправляемого com , Мне интересно, как это можно было бы сделать, или это будет достигнуто взад и вперед даже больше, чем в управляемом C++.

Возможно ли это, и если да, то как, или есть что-то, что я не понимаю по поводу концепции и взаимодействия?

+0

Это бесцельная микро-оптимизация. Офисные приложения - это внепроцессные серверы. Выполнение вызова interop довольно дорого, для него всегда требуется переключатель контекста потока, а также стоимость сериализации аргументов функции и возврата результата функции. Десятки тысяч циклов процессора. Никто не может видеть ваше улучшение в 1%. Если вы хотите сделать это быстрее, вам нужно написать надстройку. Код, который выполняется внутри процесса Office и, следовательно, может избежать затрат, связанных с необходимостью преодоления границы процесса. –

ответ

-1

Я хотел бы использовать родной неуправляемого C++ манипулировать COM-объект (ы) для некоторых более интенсивной работы

Но вы не используете неуправляемого C++, а не C++/CLI (управляемый C++) используются:

Microsoft::Office::Interop::Outlook::_Application^ OutlookApp() 
{ 
    return dynamic_cast(HostApplication); 
} 

Если вам необходимо, чтобы избежать использования рамок .net Я бы предложить разработку неуправляемого COM надстройки, который реализует интерфейс IDTExtensibility2 или отдельное приложение.

0

Это границы процесса Я предполагаю, что управляемый C++ до сих пор не обрабатывается офисными приложениями. Поэтому все еще довольно медленно. Похоже, это хорошая причина для использования Delphi.