VisualBasic functions are slower?

I have stumble into this article that are telling using Visual Basic functions (its in the 3.1 section) in .Net is proven to be slower that their .Net counterparts, I just wish to be clarified if this is true...

At first look its from a beginner and the only reply states that he stole the copyright guidelines since he did not write it himself. Also the comment was from 3/31/2005 and noboby else has commented on it?

Something does not add up so I actually looked at it. It was writtten by someone else back in 2004!

Quote:

---

Originally Posted by Steve Sartain

Making use of the original Visual Basic functions has been proven to be up to 1000 times slower than the .NET counterparts; you have been warned.

---

Where's the proof to back this claim up? To me, this proves and disproves absolutely nothing.

Its items from the VisualBasicCompatiblity namespace and yes it is true.

I skimmed through the article and didnt see anything on it. Did you learn this from the article or other source? :)

When you decompile the .NET assemblies you'll see that most of the methods in the VisualBasic namespace (if not all) are either wrappers for .NET methods or are methods that use .NET methods.

Yes, that is true but every post I read on that always states that any difference in performance is miniscule in measure. Where is it shown that its a 1000 times slower?

I don't find it a very enlightening article in general.

With that 'doubtful' section, could it be assumed that the whole article is not worthy to follow?

Just like you shouldnt judge a book by its cover, you shouldnt judge the article by one mistake. With a bit of common sense applied when reading it there should be some benefit from its contents. Not a whole lot since like I posted, only a single comment posted. ;)

I don't think the performance hit is very large but there is one.
"Microsoft.VisualBasic.Compatibility Namespace
The Visual Basic 6.0 Compatibility library is distinct from the Visual Basic Runtime. The Microsoft.VisualBasic.Compatibility namespace is used by the tools that upgrade Visual Basic 6.0 code to Visual Basic .NET. It is a bridge to support Visual Basic 6 features that are not directly supported by the .NET implementation of Visual Basic. Unlike the Visual Basic Runtime, the compatibility library is not implicitly referenced by all Visual Basic .NET applications. When you upgrade a Visual Basic 6 project to Visual Basic .NET, the upgrade wizard adds a reference to Microsoft.VisualBasic.Compatibility.

The compatibility classes should not be used for new development. The Microsoft.VisualBasic.Compatibility namespace adds a layer of complexity to your Visual Basic .NET application and introduces some minimal performance costs that could be eliminated by recoding portions of the application. In addition, the Compatibility namespace often contains many classes that wrap COM objects, and as stated earlier, depending on COM objects is not as optimal as a pure managed implementation. However, the library itself is not overly inefficient and the performance costs will probably not be noticeable in most applications. The rest of this section highlights a few prevalent Visual Basic 6 compatibility features and their performance characteristics."
http://msdn.microsoft.com/library/de...tinternals.asp

http://visualbasic.about.com/library.../aa062103c.htm

http://addressof.com/blog/articles/C...uidelines.aspx

Ultimately its a personal decision and not a very big deal.

Quote:

---

However, the library itself is not overly inefficient and the performance costs will probably not be noticeable in most applications.

---

Thanks Ed. Just as I thought. Its a very minimal difference but the Compatibility namespace is the real dinosaur. ;)

Yes and it is important to realize that the VisualBasic.Compatibility namespace is not the samething as the VisualBasic namespace and is not required for VisualBasic.

So that means that section is actually referring to VisualBasic.Compatibility and not to VisualBasic NameSpace?

Quote:

---

Originally Posted by dee-u

So that means that section is actually referring to VisualBasic.Compatibility and not to VisualBasic NameSpace?

---

Correct.

Darn... :blush: I should edit this thread's title then...

As has been said, the Micosoft.VisualBasic.Compatibility namespace is something completely seperate to the Visual Basic Runtime. As I've stated before, all VB.NET Runtime functions are written in 100% VB.NET, so there is no reason to believe that calling a Runtime function would be any slower than calling a function of your own creation that would then call the corresponding System-based property or method. For instance, the Left function would be implemented much like this:

VB Code:

Public Function Left(ByVal Str As String, ByVal Length As Integer) As String
    If Length < 0 Then
        Throw New ArgumentException("Some message here.")
    End If
 
    If Length >= Str.Length Then
        Return Str
    End If
 
    Return Str.Substring(0, Length)
End Function

There is then the overhead of an additional method call but that difference would be miniscule and completely undetectable unless you were calling Runtime functions in very large numbers.

I just had a read of that paper and it seems pretty good stuff all up, but that bit about Runtime functions does sound dubious. There may be some very isolated, special case or cases where that statement about them being 1000 times slower is correct, but they are just VB.NET functions like any other. My advice, as always, is to leave the Microsoft.VisualBasic reference where it is but use System-based methods and properties wherever possible. Only use Runtime functions when they add some genuine value. If you are concerned that you might be using Runtime functions without realising it then here's a good rule of thumb. All methods must be qualified with the name of a class for Shared members, or the name of an instance, i.e. a variable. The only exceptions to this are in-built VB.NET functions and methods in a module. The in-built functions are easy to spot because they turn blue in the IDE, so if you type an unqualified method name and it doesn't turn blue then it must be a member of a module. If it is not in a module of your own creation, then it is almost certain to be a Runtime function. You can click it and press F1 to go to the relevant help topic to confirm this.

In addition to all this, VB.Net is on average about 3% slower than C# for normal day to day stuff.

This is from my own observations, although MSDN does have several pages that do reflect this.

Yeah legacy VB methods are butt-slow and are bad practice anyway so only a fool would contamplate using them.

Quote:

---

Originally Posted by wossname

In addition to all this, VB.Net is on average about 3% slower than C# for normal day to day stuff.

This is from my own observations, although MSDN does have several pages that do reflect this.

Yeah legacy VB methods are butt-slow and are bad practice anyway so only a fool would contamplate using them.

---

Hmmmnnn... I thought when they are compiled to IL then there will be no difference in their speed?

The IL produced by VB.NET and C# is usually very similar and often identical. Overall, though, C# does produce more efficient IL. The thing is, for most everyday applications that difference is imperceptible because the application spends most of its time waiting for the user. Only computationally-intensive applications will show a significant performance edge when written in C# rather than VB.NET.