This is a recurring question among our prospect customers. The general idea is that a support library can't avoid adding some overhead to the migrated application.
However, this is just another false myth and in fact we can easily prove that a support library can often make your application faster, not slower. Let's divide the explanation in four parts.
1) Basic member wrappers
The vast majority of the classes and methods in VB Migration Partner's library are just verythin layers over the corresponding .NET control. For example, this is the code for the SelText property of the VB6TextBox control:
Public Class VB6TextBox
Inherits System.Windows.Forms.TextBox
' ...(all other properties and methods have been omitted)
Public Property SelText() As String
Get
Return MyBase.SelectedText
End Get
Set(ByVal value As String)
MyBase.SelectedText = value
End Set
End Property
End Class
NOTICE that the VB6TextBox class inherits from System.Windows.Forms.TextBox, therefore it is a 100% native .NET control. Only the few members whose name or behavior differ from the VB6 counterpart need to be overridden. Also, notice that re-exposing a .NET property with the VB6 name ensures that migrated apps work also if the control is accessed via late-binding. None of our competitors can’t handle the late-binding case correctly and they require that you manually tweak the migrated code.
As you see, the wrapping property just forward the call to the base class. Interestingly, the .NET Just-in-time compiler uses an optimization technique known as code inlining, which guarantees that the SelText property is sidestepped and that the client app directly invokes the SelectedText member in the base class. In short, no performance penalty occurs for simple wrapping members.
2) Wrappers with additional statements
A method in the support library may include additional statements, in order to preserve functional equivalence with the original VB6 code. For example, in VB6 an assignment to the SelStart property also resets SelLength and brings the cursor into view. We keep the functional equivalence by adding a couple statements in the wrapping property:
Public Property SelStart() As Integer
Get
Return MyBase.SelectionStart
End Get
Set(ByVal value As Integer)
MyBase.SelectionStart = value
MyBase.ScrollToCaret()
' in VB6 setting SelStart resets Sellength
MyBase.SelectionLength = 0
End Set
End Property
The code inlining optimization technique described above avoids the call overhead even in this case, yet it is true that these additional actions may introduce a minor overhead.
The point not to be missed, however, is that developers working at the migration should add those statements anyway to preserve functional equivalence. Having these statements located in the library instead of in the migrated code brings several advantages, including
- Developers save time because apps migrated work well at the first attempt
- Developers don’t need to be “migration gurus” nor they need to be aware of the thousands major and minor differences between VB6 and .NET
- The code in the migrated app is more readable and can be maintained more easily, because it doesn’t contain all the extra (and obscure) statements that ensure that VB.NET code works exactly like VB6.
- The migrated app is therefore smaller and loads faster
Please notice that over 95% of the methods and properties defined in our support library fall in either case 1 or 2. None of them adds any performance penalty to migrated apps. Better, they make your code more concise and faster!
3) Methods that have no .NET equivalent
Fewer than 5% of the members in VB Migration Partner's support library have no direct equivalent in the .NET Framework. For example, this is the case with graphic methods (Line, Circle, etc.), drag-and-drop statements, and DDE keywords. Of course you *CAN* implement graphics and drag-and-drop under .NET, but consider that this isn't an easy task because the VB6 and .NET programming models are very different. Not surprisingly, only VB Migration Partner can automatically convert these VB6 features, thanks to its support library.
Because is no direct .NET counterpart exists and no other VB6 conversion tool supports these features, it's impossible to measure the overhead that our library adds in these cases. At any rate, we concede that an expert .NET developer might be able to re-write the graphic or drag-and-drop portions of your software so that it runs faster than the code migrated from VB6.
As usual, the decision is a trade-off of cost/time against performance. VB Migration Partner can convert a graphic-intensive VB6 application into a reasonably fast .NET graphic application. Maybe you can make youre code run faster if you manually rewrite those graphic statements using native GDI+ methods. On the other hand, you're surely going to spend a lot of time and money in the process, without any certainty to achieve a result that is noticeably faster than what VB Migration Partner delivers to you in a few seconds and for free.
4) Helper performance-wise classes and methods
Finally, don't forget that in many cases when a support library can actually make your migrated code faster, not slower. VB Migration Partner's support library includes several helper classes that have been designed with performance in mind. A great example of this concept is the StringBuilder6 helper class, that can speed up string concatenation by two or three orders of magnitude, as explained here.
The StringBuilder6 class is nothing but a wrapper for the well-known System.Text.StringBuilder class, thus you might optimize the migrated code by using either class. The big difference is that using the StringBuilder6 class only requires that you insert one single SetType pragma in the original VB6 code, whereas using the standard StringBuilder forces you to manually modify the generated code in many places, because the StringBuilder object calls for a different syntax.
VB Migration Partner's library also offers auxiliary classes to speed up collections, and the VB6Collection helper class is much faster than the standard VB.NET collection in nearly all circumstances, as explained in this article.
VB Migration Partner's support library is written in standard VB.NET, therefore all the performance improvements it offers could be theoretically achieved by modifying the VB.NET code generated by any conversion tool, for example Artinsoft's VBUC. However, these manual optimizations require some time (often, a LOT of time) and are error-prone, therefore in practice they are seldom carried out unless the migrated code is just too sluggish to be used.
Bottom line: VB Migration Partner and its support library generate .NET apps that run faster than those produced by any other competing product, and rarely require that you manually optimize the generated code.
Still not convinced? Then wait no longer: ask for VB Migration Partner Trial Edition and compare it against any other VB6 conversion tool, or against your .NET programming skills. The faster wins.
).
