Breaking the interface is a definite no no. We have too many components that use the interface, and we can't afford the effort it would take to change them all. However - would coding some COM/VB wrappers around the components do the trick?
I have to say, however, that I'm a bit confused as to why this would help (but then again I'm no COM expert!). Surely the data will still have to marshalled from the unmanaged code of the VB components into the managed .NET code? Thanks Simon > -----Original Message----- > From: Chad M. Gross [mailto:[EMAIL PROTECTED] > Sent: 19 June 2003 18:31 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] COM Interop and Threading > > > Your performance problem may be related to your VB parameters > being ByRef. If you have the ability to break the > compatability of your interface and use ByVal, you could > return an object that contains the messageData, messageFound, > and the opSuccess information you require in the FindMessage > call. Your other two calls may also be able to have ByVal parameters. > > Chad > > On Wed, 18 Jun 2003 16:39:32 +0100, Simon Jefford > <[EMAIL PROTECTED] LTD.COM> wrote: > > >I am currently having a performance issue with a .NET > application I am > >working on. The application consists of a Windows Service > which spawns > >a number of controller objects. Each of these controllers > has a Start > >method which is executed on a new thread. > > > >The Start method looks a little bit like this: > > > >while (_running) > >{ > > bool opSuccess = listener.FindMessage(ref messageData, ref > >messageFound); > > if (opSuccess && messageFound) > > { > > opSuccess = processor.ProcessMessage(ref messageData); > > } > > if (opSuccess) > > { > > opSuccess = dispatcher.DispatchMessage(ref messageData); > > } > >} > > > >The listener object is configured to look in a certain place > (normally > >a > >MessageQueue) for some data to be processed. The processor > object does > some > >work on that data and the dispatcher object sends it off to another > >MessageQueue. > > > >Here's the thing. The listener, processor, dispatcher and > messageData > >objects are all COM objects which each implement a certain > custom COM > >interface (IListener, IProcessor etc). I think this is what may be > >killing the performance of the app. With more than 2 or 3 controller > >objects (and therefore threads) running the throughput is lousy - 1 > >message every 4 or > 5 > >seconds. The "Number of Marshals" .NET performance counter climbs to > around > >8000 after about 1 minute of the app running. My suspicion > is that with > more > >than 2 or 3 controller objects executing, there is just far too much > >marshalling from managed to unmanaged code, and vice versa. > The service > I'm > >writing is intended to be a replacement for a VB6 app which has much > >the same functionality, hence the "legacy" COM components. > All of these > >components are coded in VB6 also. > > > >Can anybody shed some light onto whether my suspicion is correct or > >not? > > > >Thanks in advance > > > >Simon Jefford > > > > > >_____________________________________________________________ > __________ > >_ > >This email has been scanned for all viruses by the MessageLabs Email > >Security System. http://www.messagelabs.com > >_____________________________________________________________ > ___________ > > ______________________________________________________________ > __________ > This email has been scanned for all viruses by the > MessageLabs Email Security System. http://www.messagelabs.com > ______________________________________________________________ > __________ > ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs Email Security System. http://www.messagelabs.com ________________________________________________________________________
