Does a support library add any performance overhead?

clock May 9, 2011 13:08


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 very thin 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.



The quest for transparency

clock May 6, 2011 11:27

I always have fun at browsing our competitors' website, especially when they have to explain which VB6 features they support or don't support, or when they attempt some bold comparisons with THEIR competitors (that is, us!)

For one, I can't help admiring the intentional vagueness that they often use when describing which controls their tool support. To them "supporting a control" is a binary property, it's either TRUE or FALSE.

Just to give you a concrete example, all the VB6-to-.NET conversion tools claim that they support the PictureBox control. Alas, they forget to mention that they

  • don't support the PictureBox as a container
  • don't support graphic methods, double buffering, and custom ScaleMode settings
  • don't support DDE
  • don't support drag-and-drop (neither "classic" nor OLE flavors)
  • don't guarantee that all events are fired or are fired in the correct order
  • ... and counting

As you look at it more closely, the "We support the XXX control" claim is void, unless you explicitly specify which features are supported, which ones aren't, and those that are supported only partially. The devil is the details, as they said, and many customers discover these details only after purchasing the software.

We believe this approach is ethically questionable and for this reason we always made the entire documentation for VB Migration Partner is available online, so no one can get unpleasant surprises AFTER purchasing our software. In addition to the manual we also make available the entire Knowledge Base, which orderly lists all known defects and limitations (and how to work around them). For sure this isn't a common attitude in the world of software, as our customers can attest.

In our quest for the highest transparency, we have prepared a long and detailed document (also in PDF format) that explains all the features as well as all the limitations of VB Migration Partner's support library, including the slightest differences from VB6, and - above all - how to work around them. This information has always been available on our website, but finally our customers have a single document that gathers the information spread in hundreds of different KB articles.

It is a safe bet affirming that all software vendors maintain a list of known issues with their tool, as we do, but you won't find this list available on our competitors' websites.... Too embarassing?