Porting a Win32 Delphi App to .Net

I have been using Delphi since version 1.0. When Delphi first appeared on the market, it blew the doors off Visual Basic 3.0. It was a rapid application development platform which compiled code down to native machine code, and allowed the creation of all new visual components using the same Delphi environment. Delphi used a beautiful object oriented language, Turbo Pascal, which had proven itself in past Borland products. Since everything was compiled into a single EXE or DLL, you avoided the Visual Basic DLL/VBX version hell. Delphi version 2.0 brought 32 bit support, and continued dominance over VB 4.0.

And now, to the present! The company I work for provides a fairly complex loan calculation engine, which is written using Borland Delphi for the 32 bit Windows platform. Lots of numerical calculations wrapped in iterative loops, etc. Since it is a standard, 32 bit Windows DLL, we can provide many different ways for our customers to access it:

1. The standard LoadLibrary() / GetProcAddress() win32 routines.
2. We provide a wrapper class for those developing on the .Net platform in vb or C#.
3. If using Java on Windows, we even provide a Java wrapper class which accesses the DLL via JNI.
4. If using Delphi, you can link to it in code easily.
5. We even provide a Win32 service which listens on a specified TCP/IP port to service requests from non-win32 platforms.
   

All this is well and good. Performance is outstanding, with a couple hundred requests per second being handled under optimal situations - and there was much rejoicing!

However, a situation has come up wherein a potential client who uses C# to develop their application has requested that we port the DLL over to the .Net platform. Why? Because one of their huge selling points is that, "Our software is pure .Net".

I won't go into my initial "WTF?" reaction, and rant against rewriting a perfectly good and accessible calculation engine just for the sake of what amounts to code related religious fanaticism. When it comes down to it, the customer asks, and we do what we can to accommodate.

With this in mind,we looked at a few possible options: rewrite it the 70K+ lines of code in C#, license our source code to the prospective customer and have them rewrite it, or investigate Delphi for .net.

We dismissed option #1 as being too time consuming for a small company, considered option 2 as sub optimal, and have for now gone with option #3. In about a week, I was able to compile a portion of our calculation engine DLL using Delphi for .Net.

And then I ran a test calculation... and waited... and waited. It took 2 seconds to complete a simple calculation which would have been done in the merest fraction of a second using the native Win32 DLL. We are talking about a performance differential of around 99%. Le ouch!

So now I need to look at profiling the .Net assembly, and try and figure out what the hell is causing the problem. The .Net platform could not be this horrible slow with numeric calculations, can it? It must b some sort of Borland.Vcl.dll .net implementation issue, right? Right!?!?!?

Gahhhhhhhhhh! If anyone has any ideas and/or suggestions, I'm ready and willing!