views:

78

answers:

2

I am in the process of migrating a legacy VB6 app to .Net, however since it is a high-profile business critical application, it is being done piece by piece.

In the interest of improving performance, there is one method which gets hit a lot,thousands of times during the application life, and I was wanting to rewrite it in .Net (C#) to see if the runtime can be improved.

The method in question manipulates ADODB Recordsets. Is there any performance issues I should be aware of or take into consideration since these recordsets will be passed to and from VB6 via COM interop?

+1  A: 

Unfortunately I highly doubt anyone will be able to give you any information regarding your situation that you don't already know. You mentioned that you're passing recordsets to and from VB6 which I can only assume means that you're using the old school ADO COM object from within .Net.

Ick.

So assuming there was no other way I can only conclude I have no idea what kind of technical hurdles you're running into that would force you to commit such an atrocity. I can merely wish you the best of luck.

Spencer Ruport
Unfortunatly the tightly coupled nature of the application means making wide spread changes difficult to implement, so I am looking for small chunks to at a time.
benPearce
No doubt. I've been in similar situations before so I'm not critiquing your approach. I'm just explaining without a working knowledge of the application I can hardly give any recommendations since you may be very well forced to do the exact opposite.
Spencer Ruport
+2  A: 

I haven't done anything specific on this but from my experience with Interop, .NET is very well optimized and usually per interop call to Win API or COM only introduces nano seconds of overhead that is negligible. ADO Recordset will just be treated the same as any other COM objects created on unmanaged heap and under the hood is the IntPtr address that they deal with.

Native .NET framework library and its garbage collector is far superior than whats avaialble in VB. I believe rewriting some of your old VB code in .NET may give you some performance gain more or at least enough to ignore the interop overhead. Best if you equip yourself with a profiler tool and continuosly monitor performance as you migrate the implementation piece by piece.

Fadrian Sudaman
+1 For the first paragraph about speed of interop. I am rather skeptical about any *general* performance gain to be obtained by rewriting VB6 components in .NET. There might be specific performance gains in some specific situations.
MarkJ
The overhead is significant enough that Microsoft has written several articles about optimization techniques. http://msdn.microsoft.com/en-us/library/ms998551.aspx
Bob Riemersma