I mean no disrespect to Tim, but the problem being described here seems
architectural. The cost of creating contexts and making cross-context
method calls relative to the cost of doing real work in applications is
minimal: the sorts of slowdowns you're seeing are highly unlikely to be
caused by them (especially if you're not marshaling interface pointers
across context boundaries).

Could you send the sources for this application/test program to me? I'd
like to figure out where the perf hit is happening.

Have you considered making the references to Object 3 and Object 4
JITted references to pooled objects? If you're making 1000 method calls
to Object 2, and each method call requires Object 3 and Object 4, this
would be a big win.

To say that it's the "transactional settings" that slows things down is
not specific. When you turn on transactions, you get synchronization,
you start talking to DTC and SQL, etc etc etc. What data store are you
talking to? What mechanism are you using to pool data base connections?
What toolset are you using to pool data base connections? If you're
using ADO to talk with the database, and ADO is marked "Apartment", then
you're getting an apartment switch between your components and ADO that
you weren't getting in the earlier case. Often this involves marshaling
a lot of information.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]