All Outlook object model calls run on the main thread

While writing an Outlook addin, lots of people feel that they should try to help with Outlook performance by running their addin code on a background thread. While this can help in some scenarios it can actually make things worse in others, particularly if the addin is interacting primarily with the Outlook Object Model (OOM). The OOM is run in a single threaded apartment COM server, therefore every COM call is executed on the main thread of outlook.exe.

If an addin is interacting with the OOM from another apartment (i.e. on a background thread or another process) all the calls have to be marshaled to and from the server apartment (i.e. the main thread) which causes some extra overhead. This overhead is why working on a background thread could actually make performance worse and it does not exist if the addin is executing in the same apartment.

Like most things, it is a balancing act and one needs to find the proper balance for their particular situation. Just remember the key to performance is "Measure, Measure, Measure..."

6 Comments

  • One other thing is that if the call isn't marshaled into the main thread that will crash Outlook when the OOM is called. I've seen that in a few addins that tried to use background threading with the OOM.

  • Excellent point, you are certainly playing with fire if you don’t marshal and use the raw pointer on another thread. In the native programming world people need to call CoMarshalInterface/CoUnmarshalInterface to move the COM references across apartments. However, in managed code this is handled automatically for you by the runtime.

  • So,

    Does that mean you should not use a Background worker ? Most of the times, we need to work in the background because we dont want that the user has to wait till our work completes before he can do something else.

    Any ideas ?

  • Kulvinder - It is find to use a background worker if you are doing your own work and using very minimal Outlook OM but if you are heavily using the Outlook OM you aren't gaining much if anything.

  • What about non-add-ins... just separate EXE (.Net 2.0) that calls OLOM via O2003PIA's?
    Are they potentially causing Outlook to crash?

  • So, I've developed an add-in which uses a windows form with a progress bar. I want to move items from one folder to another, and have the progress bar in the form show the progress. Can I use backgroundworker to do the moving of items (obviously using OOM) and report progress back to the form using the backgroundworker's ReportProgress event? Is this safe?

Comments have been disabled for this content.