Results 1 to 1 of 1
2002-09-13, 22:10 #1
- Join Date
- Feb 2001
- Silicon Valley, USA
- Thanked 94 Times in 90 Posts
COM Wrappers (Article in 10/02 DDJ) (C++ / C# .NET)
In the October issue of Doctor Dobb's Journal (which is so hardcore, I can only understand about one article per month!), there is an interesting discussion of mixing .NET components with existing VB6 solutions. Unfortunately the article is not online, so let me give you a rough overview.
The in-house developers at Silicon Energy need to create large in-memory collections of electricity usage datapoints from local collection systems. They then need to very efficiently search these datapoints. As part of the company's evaluation of .NET, they tested whether a new caching component written in C# .NET would perform better with a VB6 consumer/client component than a traditional C++ component. Because the system is time-critical, due to its linkage with "real-time" energy trading systems, performance was critical.
Populating a sample dataset with one million datapoints and two test clients, one written in VB6 and one written in C#, they found that the fastest combination was C# client and C# server with performance times in the range of 18 seconds. In second place was VB6/C++, which required about 52 seconds to build the data collection. The worst case scenario was VB6/C#, which required about 350 seconds to complete the same task. The authors attributed this to pushing one million method calls through the COM wrapper to .NET and back again.
But the C#/C# combination was not always the fastest. In a query of the dataset, which was the operation the developers initially had sought to optimize over all others, the VB6/C# combination was marginally faster (by about 0.05 milliseconds). Whether this reflects some need for a bit more fine-tuning in .NET, or just a tad more overhead, or the developers having not yet fully adopted a .NET mindset... who knows?
In any event, the cost of redeveloping the VB6 client in C# would have been too high. Weighing the various conflicting pros and cons, the team chose C++ for the new component.
The article also describes differences in performance and memory use of the C# component as a result of choosing value or reference types. You serious .NET-heads can read that part yourselves.