Use of Return Statement

While browsing MSDN, I found an article related to performance in
VB.NET programs. The article is dated 2002, and I am not sure if the
information below is still correct:
>
http://msdn2.microsoft.com/en-us/lib...perfoptanchor5
>
Calling and Returning
>
...
>
Use the Return statement whenever your logic permits it. For more
information, see Return Statement. The compiler can optimize the code
better than if you use Exit Function, Exit Property, or Exit Sub, or
allow the End Function, End Get, End Set, or End Sub statement to
generate a return.
>
>
Now reading this, I get the impressions that I should add a return to
all of my subroutines instead of relying on End Sub. If this is
indeed true, this seems like a compiler bug that I hope has been fixed
by now.
>
Any comments on this?

>Jamil,
>
>Remember that all external actions like a .show cost more time than all
>other actions from an application. With this you almost in any situation for
>sure can not make your program faster for your user.
>
>(There are some application when you can win time, however then the question
>comes if the managed code based programs are the best for that. In those
>situation can C++ be a good choise). Know that it should be very extreme, we
>have seen a real live big sample of an application in this newsgroup where
>the VB.Net program had more performance than the same applications in C++.
>
>Cor

Given a VB.NET application that executes as a batch process with
code that executes repeatedly, I would be willing to make code
changes that saves fractions of seconds in a single procedure.
>
So, based on the link I provided, which actually executes in less
time?
>
Example 1:
Public Sub Test1(ByRef val As Long)
val += 1
Return
End Sub
>
Example 2:
Public Sub Test2(ByRef val As Long)
val += 1
End Sub
>
According to the link, Example 1 is more efficient. My point is
that if this is true, I think it's a defect in the compilation.
There
should be absolutely no difference between the two.
>
Here's a bit more code to put this into perspective:
>
Public Sub Main()
Dim start1 As Date
Dim finish1 As Date
Dim start2 As Date
Dim finish2 As Date
>
start1 = Now
>
For i As Long = 0L To 10000000000L
Call Test1(i)
Next i
>
finish1 = Now
start2 = Now
>
For i As Long = 0L To 10000000000L
Call Test2(i)
Next i
>
finish2 = Now
>
Call MsgBox(String.Format("Test1: {0} ms Test2: {1} ms", _
finish1.Subtract(start1).TotalMilliseconds,
_
finish2.Subtract(start2).TotalMilliseconds))
>
Executing this test, I received a savings of over one second. There
is a difference in time, and the MSDN article is accurate with
Visual Studio 2005 containing the latest service packs.

>I don't now what execatly the statement that Return can be optimized better
>was referrring to, so I can not give a good reason for it. Though, you are
>creating an example where Return really doesn't make sense: Just at the end
>of a Sub (Sub, not Function).
>
>In your example, it is very simple why Test1 is slower: Return causes a jump
>to the end of the procedure. In Test2 this superfluous step is left out,
>therefore it's faster.
>
>I pasted the IL code below. You don't have to speak IL, but you see that, in
>Test2, there is a "br.s" command at position IL_0010. "br" = branch = jump
>(to position IL_0012).
>
>Test1:
>
IL_0000: nop
IL_0001: ldarg.0
IL_0002: ldarg.0
IL_0003: ldind.i8
IL_0004: ldc.i8 0x1
IL_000d: add.ovf
IL_000e: stind.i8
IL_000f: nop
IL_0010: ret
>
>Tets2:
>
IL_0000: nop
IL_0001: ldarg.0
IL_0002: ldarg.0
IL_0003: ldind.i8
IL_0004: ldc.i8 0x1
IL_000d: add.ovf
IL_000e: stind.i8
IL_000f: nop
IL_0010: br.s IL_0012
IL_0012: nop
IL_0013: ret
>
>
>This is the Debug build. Using the Release build, the execution time is
>exactly the same, which means that the superfluous jump has been
>optimized-away.
>
>Well, it was /you/ putting an additional Return statement there to make it
>slower. ;-)
>
>
>Armin

>On Thu, 9 Aug 2007 01:37:53 +0200, "Armin Zingler"
><az.nospam@freenet.dewrote:
>
>In my test, Test1 is actually faster with a release build. I have a
>savings of over one second (which corresponds to the MSDN article).
>Is it a hardware difference? Not sure.
>
>Your MSIL is also very different than mine though.

Cor,
>
I know what you are stating, but I am not quite sure why you are
stating it. I am not debating whether VB.NET or C/C++ is a better
development language. I simply wanted confirmation on a published
Microsoft recommendation. They spent time and resources on publishing
it, so it must have been for a reason.
>
Given a VB.NET application that executes as a batch process with code
that executes repeatedly, I would be willing to make code changes that
saves fractions of seconds in a single procedure.
>
So, based on the link I provided, which actually executes in less
time?
>
Example 1:
Public Sub Test1(ByRef val As Long)
val += 1
Return
End Sub
>
Example 2:
Public Sub Test2(ByRef val As Long)
val += 1
End Sub
>
According to the link, Example 1 is more efficient. My point is that
if this is true, I think it's a defect in the compilation. There
should be absolutely no difference between the two.
>
Here's a bit more code to put this into perspective:
>
Public Sub Main()
Dim start1 As Date
Dim finish1 As Date
Dim start2 As Date
Dim finish2 As Date
>
start1 = Now
>
For i As Long = 0L To 10000000000L
Call Test1(i)
Next i
>
finish1 = Now
start2 = Now
>
For i As Long = 0L To 10000000000L
Call Test2(i)
Next i
>
finish2 = Now
>
Call MsgBox(String.Format("Test1: {0} ms Test2: {1} ms", _
finish1.Subtract(start1).TotalMilliseconds, _
finish2.Subtract(start2).TotalMilliseconds))
>
Executing this test, I received a savings of over one second. There
is a difference in time, and the MSDN article is accurate with Visual
Studio 2005 containing the latest service packs.
>
On Wed, 8 Aug 2007 19:39:04 +0200, "Cor Ligthert[MVP]"
<notmyfirstname@planet.nlwrote:
>

>Yes, the only difference I see is in Debug build. If you IL code is the same
>(release config) for both subs, both /must/ take the same time (in theory),
>so the 1 second for such a long loop - I made a shorter loop and used the
>StopWatch, as Göran did - can vary for any reason.
>
>
>Armin