vb. net optimizing

[nemaroller]

Use Early Binding
The second concern deals with objects and typecasting. Visual Basic 6 does a lot of work under the hood to support casting of objects, and many programmers aren't even aware of it. In Visual Basic 7, this is an area that out of which you can squeeze a lot of performance. When you compile, use early binding. This tells the compiler to insert a Type Coercion is only done when explicitly mentioned. This has two major effects:

Strange errors become easier to track down.
Unneeded coercions are eliminated, leading to substantial performance improvements.
When you use an object as if it were of a different type, Visual Basic will coerce the object for you if you don't specify. This is handy, since the programmer has to worry about less code. The downside is that these coercions can do unexpected things, and the programmer has no control over them.

There are instances when you have to use late binding, but most of the time if you're not sure then you can get away with early binding. For Visual Basic 6 programmers, this can be a bit awkward at first, since you have to worry about types more than in the past. This should be easy for new programmers, and people familiar with Visual Basic 6 will pick it up in no time.

Turn On Option Strict and Explicit
With Option Strict on, you protect yourself from inadvertent late binding and enforce a higher level of coding discipline. For a list of the restrictions present with Option Strict, see the MSDN Library. The caveat to this is that all narrowing type coercions must be explicitly specified. However, this in itself may uncover other sections of your code that are doing more work than you had previously thought, and it may help you stomp some bugs in the process.

Option Explicit is less restrictive than Option Strict, but it still forces programmers to provide more information in their code. Specifically, you must declare a variable before using it. This moves the type-inference from the run time into compile time. This eliminated check translates into added performance for you.

I recommend that you start with Option Explicit, and then turn on Option Strict. This will protect you from a deluge of compiler errors, and allow you to gradually start working in the stricter environment. When both of these options are used, you ensure maximum performance for your application.

Use Binary Compare for Text
When comparing text, use binary compare instead of text compare. At run time, the overhead is much lighter for binary.

Minimize the Use of Format()
When you can, use toString() instead of format(). In most cases, it will provide you with the functionality you need, with much less overhead.

Use Charw
Use charw instead of char. The CLR uses Unicode internally, and char must be translated at run time if it is used. This can result in a substantial performance loss, and specifying that your characters are a full word long (using charw) eliminates this conversion.

Optimize Assignments
Use exp += val instead of exp = exp + val. Since exp can be arbitrarily complex, this can result in lots of unnecessary work. This forces the JIT to evaluate both copies of exp, and many times this is not needed. The first statement can be optimized far better than the second, since the JIT can avoid evaluating the exp twice.

Avoid Unnecessary Indirection
When you use byRef, you pass pointers instead of the actual object. Many times this makes sense (side-effecting functions, for example), but you don't always need it. Passing pointers results in more indirection, which is slower than accessing a value that is on the stack. When you don't need to go through the heap, it is best to avoid it.

Put Concatenations in One Expression
If you have multiple concatenations on multiple lines, try to stick them all on one expression. The compiler can optimize by modifying the string in place, providing a speed and memory boost. If the statements are split into multiple lines, the Visual Basic compiler will not generate the Microsoft Intermediate Language (MSIL) to allow in-place concatenation. See the StringBuilder example discussed earlier.

Include Return Statements
Visual Basic allows a function to return a value without using the return statement. While Visual Basic 7 supports this, explicitly using return allows the JIT to perform slightly more optimizations. Without a return statement, each function is given several local variables on stack to transparently support returning values without the keyword. Keeping these around makes it harder for the JIT to optimize, and can impact the performance of your code. Look through your functions and insert return as needed. It doesn't change the semantics of the code at all, and it can help you get more speed from your application.

http://msdn.microsoft.com/library/de...tperftechs.asp

[Slow_Learner]

Thanks for the tips!

[Cander]

I would assume using Return in subs helps too, not just functions. (A Sub is a function that dopesnt return anything)

[VictorB212]

MSDN states that a Char is an unsigned word, so I believe you can delete the section about Charw.

[nemaroller]

Those suggestions were from MSDN... look at the link at the bottom of them... http://msdn.microsoft.com/library/de...etperftips.asp

[VictorB212]

Do you blindly accept everything Microsoft says?

[nemaroller]

You're asking a guy who wears a KILL AOL shirt....

[Hu Flung Dung]

Originally posted by nemaroller
Use Charw
Use charw instead of char. The CLR uses Unicode internally, and char must be translated at run time if it is used. This can result in a substantial performance loss, and specifying that your characters are a full word long (using charw) eliminates this conversion.

Isn't there a .NET function for that? I mean that (correct me if I'm wrong) when you use the old VB-specific functions, their just calls to other .NET functions under the hood, and using them is quite a bit slower than calling those functions yourself (Example: The VB-specific Mid() function is just calling String.Substring(), so using it is quite a bit slower than calling String.Substring() directly because there's more overhead).

[nemaroller]

Chr sounds familiar to the VB6 version, but it is NOT part of the Compatability namespace, it is part of the System.Text namespace and it is new for .Net.

The fact that its syntax is exactly similiar to the VB6 function is easy for us, perhaps was done by design, but it is part of the .Net library.

So yes, there is a .Net function for it, its called Chr.

Can I leave that segment up now ?

[Hu Flung Dung]

Originally posted by nemaroller
Chr sounds familiar to the VB6 version, but it is NOT part of the Compatability namespace, it is part of the System.Text namespace and it is new for .Net.

The fact that its syntax is exactly similiar to the VB6 function is easy for us, perhaps was done by design, but it is part of the .Net library.

So yes, there is a .Net function for it, its called Chr.

Can I leave that segment up now ?

I cannot find the Chr function in the System.Text namespace! Are you sure you're not talking about the one in the Microsoft.VisualBasic namespace? I'm pretty sure that those ones are just calling other .NET functions that produce the same functionality, ie. more overhead!

[nemaroller]

HMm... yes, I just looked for it too... its not in the Compatability or the System.Text namespace....

but regardless, Char.Parse, or char.GetNumericValue is slower than using CharW....

that was probably the whole point of Char segment...

[Hu Flung Dung]

Originally posted by nemaroller
HMm... yes, I just looked for it too... its not in the Compatability or the System.Text namespace....

but regardless, Char.Parse, or char.GetNumericValue is slower than using CharW....

that was probably the whole point of Char segment...

Holy Cow! You're Right! Here's the code I tested:

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        Dim X As Char = "A"
        Dim A As Int64
        Dim lngNow As Long

        lngNow = Now.Ticks()

        For A = 0 To 1000000000

            Char.GetNumericValue(X)

        Next

        MessageBox.Show("GetNumericValue: " & (Now.Ticks - lngNow).ToString())

    End Sub

    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click

        Dim X As Char = "A"
        Dim A As Int64
        Dim lngNow As Long

        lngNow = Now.Ticks()

        For A = 0 To 1000000000

            AscW(X)

        Next

        MessageBox.Show("ASCW: " & (Now.Ticks - lngNow).ToString())

    End Sub

GetNumericValue is roughly 2.7 times SLOWER than AscW!!!
As a matter of fact, if you replace AscW with just Asc, its still 1.5 times faster than GetNumericValue!!!

However, this is VS2002! I have yet to test this out on 2003! From what I've read, I should get VERY different results!

[SuperSparks]

I have 2003, and I just tried out that exact code copied & pasted:

Button1 = 508,593,750

Button2 = 103,906,250

So there's still a big difference.

[Hu Flung Dung]

Originally posted by SuperSparks
I have 2003, and I just tried out that exact code copied & pasted:

Button1 = 508,593,750

Button2 = 103,906,250

So there's still a big difference.

Umm, why is button 1 2x slower in VS2003 than in 2002? For button 2, you got a similar speed to mine!

(P.S. I noticed it makes a BIG difference if you select 'release' mode, then run the EXE itself, not from the IDE. Thats how I ran my benchmarks).

[SuperSparks]

OK, I tried it that way and got:

Button1 = 213,906,250

Button2 = 70,781,250

Thanks for that tip BTW, I had no idea it made such a big difference in release mode. I'll remember that for the future