COM Object performance in different Threads

Ben,

COM objects have apartment affinity. By default, the UI thread (the
main thread in your .NET application) is a STA thread, and when you create
your COM object, it is associated with that apartment (it is an STA thread
because of the STAThread attribute attached to your main method).

Now, when you create your new thread, by default, it doesn't live in a
COM apartment. When you make the first call to COM interop, if you havent
set the ApartmentState property on the Thread to a value, it will place the
thread in the multithreaded apartment. Now, when you make calls to the COM
object from that thread, if you marshaled the reference correctly (which you
are not, I am sure, and I don't believe COM interop does this by default),
then all calls will be made through a proxy so the call will be executed on
the correct thread.

In the end, you are either going to have to marshal the reference
correctly (through the use of the global interface table, and a lot of
interop), or create the COM objects on the thread they are going to be used
(and make sure to set the ApartmentState property of the thread to STA
BEFORE you create any COM objects on that new thread).

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Ben Childs" <bchilds@wpidotedu> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

Hi,

I am writing an application in C# (VS.NET 2002) that runs performance
intensive analyses on data sets. In order to keep the UI responsive I have
created a seperate thread to do the analysis.

I am using my own DLLS to load the data sets from files and run the
analyses. But I have run into a bit of a problem. If I load the data set
in the main thread and then run the analysis in the seperate thread the
analysis takes about 20 times longer than usual. In addition when I try to
display the results in the gui they take forever to display. So it seems
that accessing COM objects from different threads than they were created
in is really slow. Is there any way around this?

One solution for me would be to create a thread that handled all of the
com objects, however this would be a lot of work and I was wondering if
there was a simple solution.

Thanks,

-Ben Childs

"Ben Childs" <bchilds@wpidotedu> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

Hi,

I am writing an application in C# (VS.NET 2002) that runs performance
intensive analyses on data sets. In order to keep the UI responsive I have
created a seperate thread to do the analysis.

I am using my own DLLS to load the data sets from files and run the
analyses. But I have run into a bit of a problem. If I load the data set
in the main thread and then run the analysis in the seperate thread the
analysis takes about 20 times longer than usual. In addition when I try to
display the results in the gui they take forever to display. So it seems
that accessing COM objects from different threads than they were created
in is really slow. Is there any way around this?

One solution for me would be to create a thread that handled all of the
com objects, however this would be a lot of work and I was wondering if
there was a simple solution.

Thanks,

-Ben Childs

I see two fundamental problems here.
When you create an instance of a COM object in the main (UI) thread , your
COM methods will execute on the UI thread, irrespective the thread that is
calling a method.
When you calls a method from the UI thread itself, the call is said to be a
direct call, however, when called from another thread (passing the reference
to the objects CCW to the other thread) the call must be marshaled to the UI
thread, this marshaling is done by posting windows messages to the UI
thread's message queue where they are picked up and dispatched to you COM
method which executes the call obviously on the UI thread. The marshalin
overhead make the call somewhat slower, but in general this is not such an
issue.
However, in your scenario, where you are updating the UI from the auxiliary
thread (using Control.BeginInvoke I hope, but I'm afraid you don't) things
get even more slower as the UI thread has to update the UI AND run the
analysis code, in the mean time your auxiliary thread is doing almost
nothing.

One possible solution for this is to:
- create an aux. thread,
- initialize this thread to enter a STA,
- start the thread,
- create an instance of your COM object on this thread and call the COM
methods from here,
- marshal the calls to the UI thread by calling Control.BeginInvoke to
update the UI.

Willy.