Okay here's the (quick) setup: We had a very fundamental vb dll, that was the core to the majority of our business logic. It's not a very complex set of classes, and could have been much more functional (and better) in another language that supported OO. .Net comes along and we are trying to transition away from new development in VB to new development in C#. This means that we have a couple choices for our core set of classes:
1. Simply use COM interop to reference the vb dll and extend from there. 2. Rewrite in C# (not very long to do) and maintain two sets of code. 3. Rewrite in C# and turn the vb classes into a wrapper for the appropriate C# classes. We chose #3, and the way it works is incredibly simple: * C# classes * C# "interop" class, that is responsible for creating and returning references to the appropriate C# classes (because I don't want public default constructors when they don't make sense). * VB classes have an instance of the interop class (actually it's a global module-level variable), and then each class contains a reference to the appropriate C# class, forwarding all method and property calls to the appropriate method and property. The references to the C# classes in VB are declared as Objects. Everything went very smooth until it got to the point of performance testing. The .NET classes by themselves are fast. Fast as one would expect them to be. However, when the layer of interop is added, they are SLOOOOOWWWW. Roughly 4x slower than the VB-only version. Now, I initially assumed it was that I hadn't generated a type library and "early bound" my Object variables to the appropriate types. So I exported the typelib, no more CreateObject, etc, and it's still slow (no visible improvement). I've been through the MSDN docs on interop and can't find anything that seems really important that I haven't done. Anyone have any thoughts or suggestions? You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
