No performance improvement for MultiThreaded call to a VB COM

[wdwedw]

I have included all the source codes in the attached MyTest.zip
(http://www.codeguru.com/forum/attach...chmentid=11218)

There are three projects:
VBTestCOM project is a apartment threaded DLL, it has one function doing a
stored procedure call. This DLL will be called from C++ multithread.

C++ test project is a ATL multithreaded DLL, it just simple created
multithread, and call VBTestCom's doSPCall function in each thread.

VB client:
It set thread number and start a loop calling C++ DLL's Do function.

You need created a stored procedure in SQL Server NorthWind database like
this:
create PROCEDURE dbo.usp_Test
AS
BEGIN
insert Categories(CategoryName,[Description])
values( 'CatName', convert(varchar(30),getdate(),9))

WAITFOR delay '00:00:00.100'
end
It create a record in Categories and delay 100 milliseconds.

In C++ debug, Change the thread number and you will see no performance
improvement. Trace time in thread like this:
1 Thread
vb function call time: 109
c++ other code time: 62

2 thread
vb function call time: 156
c++ other code time: 62

3 thread
vb function call time: 256
c++ other code time: 62

It's frustrating! Help!

[Jochen Kalmbach [MVP]]

Hi wdwedw!

There are three projects:
VBTestCOM project is a apartment threaded DLL, it has one function doing a
stored procedure call. This DLL will be called from C++ multithread.

C++ test project is a ATL multithreaded DLL, it just simple created
multithread, and call VBTestCom's doSPCall function in each thread.

It's frustrating! Help!

If the VBTestCOM project is apartment-threaded (that means:
single-threaded) then *all* calls to this COM-object is serialized.

So the behaviour is by design.
If you want to improve the performance, then switch the VBTestCOM
project to both or multi-threaded.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Willy Denoyette [MVP]]

"Jochen Kalmbach [MVP]" <no********************@holzma.de> wrote in message
news:OU*************@TK2MSFTNGP09.phx.gbl...

Hi wdwedw!

There are three projects:
VBTestCOM project is a apartment threaded DLL, it has one function doing
a stored procedure call. This DLL will be called from C++ multithread.

C++ test project is a ATL multithreaded DLL, it just simple created
multithread, and call VBTestCom's doSPCall function in each thread.

It's frustrating! Help!
If the VBTestCOM project is apartment-threaded (that means:
single-threaded) then *all* calls to this COM-object is serialized.

So the behaviour is by design.
If you want to improve the performance, then switch the VBTestCOM project
to both or multi-threaded.

Which is not possible using VB, VB6 can only produce Single Threaded
Apartment (STA) or Single (that is instantiated on the "main apartment") COM
DLL's.

Willy. --
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Willy Denoyette [MVP]]

This is quite normal, your VB object is a STA object, and you initialize the
thread to enter the MTA. The result is that each call as to be marshaled
between the MTA and the STA where the object lives, this kill your
performance. Initialize your apartment for STA and try again.

Willy.
"wdwedw" <wd****@discussions.microsoft.com> wrote in message
news:98**********************************@microsof t.com...

I have included all the source codes in the attached MyTest.zip
(http://www.codeguru.com/forum/attach...chmentid=11218)

There are three projects:
VBTestCOM project is a apartment threaded DLL, it has one function doing a
stored procedure call. This DLL will be called from C++ multithread.

C++ test project is a ATL multithreaded DLL, it just simple created
multithread, and call VBTestCom's doSPCall function in each thread.

VB client:
It set thread number and start a loop calling C++ DLL's Do function.

You need created a stored procedure in SQL Server NorthWind database like
this:
create PROCEDURE dbo.usp_Test
AS
BEGIN
insert Categories(CategoryName,[Description])
values( 'CatName', convert(varchar(30),getdate(),9))

WAITFOR delay '00:00:00.100'
end
It create a record in Categories and delay 100 milliseconds.

In C++ debug, Change the thread number and you will see no performance
improvement. Trace time in thread like this:
1 Thread
vb function call time: 109
c++ other code time: 62

2 thread
vb function call time: 156
c++ other code time: 62

3 thread
vb function call time: 256
c++ other code time: 62

It's frustrating! Help!

[wdwedw]

Willy,

Is that means the VB object can only lives in STA? even though create it
from MTA. Is there no ways to improve performannce for VB object with
Multithread? What does 'Initialize your apartment for STA' mean and how?

Thanks
wdwedw

"Willy Denoyette [MVP]" wrote:

This is quite normal, your VB object is a STA object, and you initialize the
thread to enter the MTA. The result is that each call as to be marshaled
between the MTA and the STA where the object lives, this kill your
performance. Initialize your apartment for STA and try again.

Willy.
"wdwedw" <wd****@discussions.microsoft.com> wrote in message
news:98**********************************@microsof t.com...

I have included all the source codes in the attached MyTest.zip
(http://www.codeguru.com/forum/attach...chmentid=11218)

There are three projects:
VBTestCOM project is a apartment threaded DLL, it has one function doing a
stored procedure call. This DLL will be called from C++ multithread.

C++ test project is a ATL multithreaded DLL, it just simple created
multithread, and call VBTestCom's doSPCall function in each thread.

VB client:
It set thread number and start a loop calling C++ DLL's Do function.

You need created a stored procedure in SQL Server NorthWind database like
this:
create PROCEDURE dbo.usp_Test
AS
BEGIN
insert Categories(CategoryName,[Description])
values( 'CatName', convert(varchar(30),getdate(),9))

WAITFOR delay '00:00:00.100'
end
It create a record in Categories and delay 100 milliseconds.

In C++ debug, Change the thread number and you will see no performance
improvement. Trace time in thread like this:
1 Thread
vb function call time: 109
c++ other code time: 62

2 thread
vb function call time: 156
c++ other code time: 62

3 thread
vb function call time: 256
c++ other code time: 62

It's frustrating! Help!

[Carl Daniel [VC++ MVP]]

wdwedw wrote:

Willy,

Is that means the VB object can only lives in STA? even though
create it from MTA. Is there no ways to improve performannce for VB
object with Multithread? What does 'Initialize your apartment for
STA' mean and how?

In your C++ code, for each new thread call CoInitializeEx and pass
COINIT_COINIT_APARTMENTTHREADED as the second parameter. That will create a
new STA for each thread. A VB-created object can live in any one of those
apartments.

-cd

[Willy Denoyette [MVP]]

"wdwedw" <wd****@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...

Willy,

Is that means the VB object can only lives in STA? even though create it
from MTA. Is there no ways to improve performannce for VB object with
Multithread? What does 'Initialize your apartment for STA' mean and how?

STA objects are single threaded but they can live in multiple STA's and each
thread can 'enter' one single STA at a time.
Each thread will create/call the object in it's owning STA without the need
to marshal and serialize the call, beware that static (shared) variables in
your VB COM objects are shared amongst the different thread instances, so
their accesses must be synchronized anyway. I've seen many applications
using VB COM objects in multithreaded applications breaking because of this
thread-unsafe design.
Willy.

[wdwedw]

Thanks Carl and Willy.

When I created a apartment for each thread, I did see the performance was
improved!

Two more questions:
1) Is static (shared) variables means public variables in Modules? because
they shared in VB project.
2) My ATL object implemented connectionpoint and work fine before, after I
create a apartment for each thread and fire the event, I got a First-chance
exception during pDispatch->Invoke() in the Fire_ServerFuncDone(LONG nReturn)
function. What's wrong?
Thanks
wdwedw
"Willy Denoyette [MVP]" wrote:

"wdwedw" <wd****@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...

Willy,

Is that means the VB object can only lives in STA? even though create it
from MTA. Is there no ways to improve performannce for VB object with
Multithread? What does 'Initialize your apartment for STA' mean and how?

STA objects are single threaded but they can live in multiple STA's and each
thread can 'enter' one single STA at a time.
Each thread will create/call the object in it's owning STA without the need
to marshal and serialize the call, beware that static (shared) variables in
your VB COM objects are shared amongst the different thread instances, so
their accesses must be synchronized anyway. I've seen many applications
using VB COM objects in multithreaded applications breaking because of this
thread-unsafe design.
Willy.

[wdwedw]

I think I got the answer for my second question: I need to fire the event
from a different thread:
http://support.microsoft.com/kb/q280512/

"wdwedw" wrote:

Thanks Carl and Willy.

When I created a apartment for each thread, I did see the performance was
improved!

Two more questions:
1) Is static (shared) variables means public variables in Modules? because
they shared in VB project.
2) My ATL object implemented connectionpoint and work fine before, after I
create a apartment for each thread and fire the event, I got a First-chance
exception during pDispatch->Invoke() in the Fire_ServerFuncDone(LONG nReturn)
function. What's wrong?
Thanks
wdwedw
"Willy Denoyette [MVP]" wrote:

"wdwedw" <wd****@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...

Willy,

Is that means the VB object can only lives in STA? even though create it
from MTA. Is there no ways to improve performannce for VB object with
Multithread? What does 'Initialize your apartment for STA' mean and how?

STA objects are single threaded but they can live in multiple STA's and each
thread can 'enter' one single STA at a time.
Each thread will create/call the object in it's owning STA without the need
to marshal and serialize the call, beware that static (shared) variables in
your VB COM objects are shared amongst the different thread instances, so
their accesses must be synchronized anyway. I've seen many applications
using VB COM objects in multithreaded applications breaking because of this
thread-unsafe design.
Willy.

[Willy Denoyette [MVP]]

Inline

Willy.

"wdwedw" <wd****@discussions.microsoft.com> wrote in message
news:99**********************************@microsof t.com...

Thanks Carl and Willy.

When I created a apartment for each thread, I did see the performance was
improved!

Two more questions:
1) Is static (shared) variables means public variables in Modules?
because
they shared in VB project.
Exactly.
2) My ATL object implemented connectionpoint and work fine before, after I
create a apartment for each thread and fire the event, I got a
First-chance
exception during pDispatch->Invoke() in the Fire_ServerFuncDone(LONG
nReturn)
function. What's wrong?
Thanks
So it looks like have a ATL COM object AND a VB6 COM object, this is not
what you told us in the initial posting.
Who's creating the ATL object instance, who's creating the VB instance what
apartments are they in?
wdwedw
"Willy Denoyette [MVP]" wrote:

"wdwedw" <wd****@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...

> Willy,
>
> Is that means the VB object can only lives in STA? even though create
> it
> from MTA. Is there no ways to improve performannce for VB object with
> Multithread? What does 'Initialize your apartment for STA' mean and
> how?
>

STA objects are single threaded but they can live in multiple STA's and
each
thread can 'enter' one single STA at a time.
Each thread will create/call the object in it's owning STA without the
need
to marshal and serialize the call, beware that static (shared) variables
in
your VB COM objects are shared amongst the different thread instances, so
their accesses must be synchronized anyway. I've seen many applications
using VB COM objects in multithreaded applications breaking because of
this
thread-unsafe design.
Willy.