Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
To use or not use Microsoft.VisualBasic.dll (all .NET Languages could benefit?)

I’ve been working on a check list for a code review process we are starting.  As a result I’m looking into all kinds of best practice opinions in books and online.

 

One interesting opinion has been to avoid importing Microsoft.VisualBasic.  The reason given was to force developers into using pure .NET code and not older VB6 legacy syntax and keywords.

 

CInt

I tested the assertion that .NET’s System.Convert.Int32 was faster than the legacy VB6 CInt.

 

The older VB6 method of converting a string to an integer was almost 20 times slower than that of the .NET Framework.

 

Here are the CInt results.

 

 

 

Well, as it turns out this is not the end of the story.  As I continued testing and comparing the classic VB6 way of doing things against the .NET Framework I found a couple surprises.

 

1. I found that you cannot have a hard and fast rule stating that the Microsoft.VisualBasic.dll should not be used.  In some cases I see that it certainly can and should be used.

 

2. Not all methods in the Microsoft.VisualBasic.dll exist in the .NET Framework.

 

3. Work around(s) for Microsoft.VisualBasic.dll methods are sometimes faster and sometimes slower.

 

4. Equivalent methods of the .NET Framework are sometimes much slower than that of Microsoft.VisualBasic.dll.

 

These are not the results I was expecting and in fact, they were not the results I wanted.  I wanted to prove to myself that I not only didn't need Microsoft.VisualBasic.dll but that it was more efficient to code without it.

 

I was wrong.

 

As we saw earlier, the System.Convert.ToInt32 is much faster than CInt and the same is true for all the conversion functions.

 

IIF

I've always known that IIF was slower than a regular If/Then/Else statement.  I had never proven this to myself or taken the time to understand why.  Like many things we pick up these tips from other developers and assume the more experienced developer is right.  In this case it's true.

 

IIF performed much slower than using If/Then/Else.  What struck me is that I had to turn Option Strict off to use IIF or explicitly convert the results.  The reason is IIF returns System.Object.  I think this is why it is slower.  Maybe someone can confirm or deny this for me.

 

Here are the IIF performance analysis results.

 

 

 

IsNumeric

The IsNumeric method is one of those Microsoft.VisualBasic.dll methods that I could not find anywhere in the .NET Framework.  I was really surprised by this because it is an obvious method that the .NET Framework should support.

 

What I did in my test was write a quick and dirty method using the TryParse method of the Double class.  The Parse method would do the same except when the value passed is not a number an exception is raised.  The exception was so expensive that it was better to simply reference the Microsoft.VisualBasic.dll and use IsNumeric; however, the TryParse method returns True/False and does not raise an exception, keeping the method call cheap.

 

The results here are much of what I expected.  The new MyIsNumeric was about twice as fast as the classic IsNumeric method.

 

The IsNumeric results are below:

 

 

 

Now()

The Now() method of Microsoft.VisualBasic.dll was another suprise.  As it turns out, the classic Now() method out performs the new DateTime.Now method by as much as 15 times faster.

 

I don't understand why but knowing the results does alter my best practices check list.

 

Here are the Now() method results:

 

 

AscW

I was surprised again when I tested VB's AscW.  As it turns out there is no equivalent to this method in the .NET Framework as well.  This functionality could, however, be imitated by using a conversion method of and Int or Double.

 

The results are disappointing as the Framework approach was many times slower.

 

Here are the AscW and Convert.ToInt32 results:

 

 

 

IsDBNull versus row.IsNull

Here is a performance comparison between the classic IsDBNull versus the .NET Framwork DataRow.IsNull method.  The .NET Framework version is about 25% faster.

Here is a performance comparison between the classic IsDBNull versus the .NET Framwork DataRow.IsNull method.  The .NET Framework version is about 25% faster.

 

 

Conclusions

As it turns out, I can't have a hard and fast rule that says never to reference the Microsoft.VisualBasic.dll library in favor of pure .NET Framework code.  The best argument for doing so is language portability.  Even in that scenario, it seems perfectly reasonable to use the Microsoft.VisualBasic.dll library regardless of what language you are using.  C# is as capable of using this library as Visual Basic.

 

It would seem that Microsoft has a little work to do.  These methods should all be framework methods and the Microsoft.VisualBasic.dll library should fade away.

 

Here is what I will do... when coding I will...

 

1. Reference the Microsoft.VisualBasic.dll library only if I explicitly intend to use it.

 

2. I will always use the .NET Framework conversion methods and never CInt, CBool, CLong, etc.

 

3. I will never use IIF.

 

4. I'm on the fence with IsNumeric.  If I'm already referencing the VB library then I might go ahead and use it but I would not allow IsNumeric to cause me to reference it because writing my own method is more efficient anyway.  If I am already referencing the VB library then I would not write my own because I would want to name my method IsNumeric as well and that could cause a conflict or force me to fully qualify it.  So that is my compromise.

 

5. The Now() method also puts me in conflict because the VB version performs as much as 15 times faster.  I will opt to use the .NET Framework version because there is a one to one mapping of this functionality and in that scenario I will almost always select the pure Framework version.  Having said that, if performance is an issue, I will fall back on the VB version.

 

6. The VB AscW, ChrW, and other character conversion methods are time tested, high performing, and reliable.  I must opt for the classic VB methods over home grow work around(s) in the .NET Framework.

 

I'm curious what others have to say on this particular topic.  I've only spent 2 days looking at these issues so if anyone has some insight, please share it.


Posted 10-19-2006 9:58 AM by rdunaway
Filed under:

[Advertisement]

Comments

Brendan Tompkins wrote re: To use or not use Microsoft.VisualBasic.dll (all .NET Languages could benefit?)
on 10-23-2006 8:47 AM

Test

Motivos de un ensamblado wrote XNA y Visual Basic: ¿Un amor imposible?
on 05-08-2008 5:25 PM

Aprovecho el movimiento generado gracias al lanzamiento de la primera CTP de XNA 3.0 y también el reciente

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)