Jeff Mangan [mailto:[EMAIL PROTECTED]] wrote:
> well, it's more of a concern of how much overhead is involved > and what is more efficient, the overhead of creating new > objects each time, or the overhead of using > System.EnterpriseServices in general ( to use object > pooling). I do not know about it enough, so I am reading > Derek Beyer's book "C# COM+ Programming" to hopefully answer > my questions. Mainly I would just be curious for someone to > explain how the overhead of com+ is laid out, and whether the > only way to find out which to use is trial and error and see > which method performs better, or if there is a standard rule > when to and when to not use it. Well, yes there's definite runtime overhead. You can avoid most of the unwanted and undue overhead that is often associated with COM+ applications by simply using a library application instead of server application. The ability to make this mode change depends directly on the requirements of your components, but if you're just looking for object pooling functionality (per appliaction instance) you're all set. For more information on this I suggest Tim Ewald's: Transactional COM+ Building Scalable Applications[1] as it's the only book I've seen that clearly and correctly demystifies the differences between library and server applications. That said, the primary .NET overhead price you pay is that your components are always bound to a single context since they derive from ServicedComponent which derives from ContextBoundObject. All calls to and from the object will be marshaled across context boundaries. In the end, every application will differ and you should always do performance testing on your domain specific use cases. Usually the cost in runtime overhead is negligible compared to the cost of having to write the services yourself and then actually having to beat the performance overhead COM+ as well. HTH, Drew [ .NET MVP | weblog: http://radio.weblogs.com/0104813/ ] [1] http://www.amazon.com/exec/obidos/ASIN/0201615940/104-6964141-6995943 You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
