Option Strict Faster?

On page 1258 of Professional ASP.NET, Scott Guthrie says Option Strict "can
provide better performance" but doesn't say why (or how much). Can anyone
explain *why* Option Strict makes indentical code run faster?

AFAIK, early vs. latebinding and strict-type vs loose type checking are two
different things.

"Frank Oquendo" <franko@acadx.com> wrote:
>Because Option Strict forces you to identify all data types at compile time,
>not run time. Eliminating late binding has always had a dramatic impact
on
>program performance, even in VB6 and earlier.
>
>This assumes that ASP.NET is strongly typed (it wasn't in earlier releases).
>
>--
>Good judgment comes from experience.
>Experience comes from bad judgment.
>
>http://www.acadx.com
>
>
>"Beginner" <a@b.com> wrote in message news:3c1665a3$1@147.208.176.211...
>>
>> On page 1258 of Professional ASP.NET, Scott Guthrie says Option Strict
>"can
>> provide better performance" but doesn't say why (or how much). Can anyone
>> explain *why* Option Strict makes indentical code run faster?
>
>

Because Option Strict forces you to identify all data types at compile time,
not run time. Eliminating late binding has always had a dramatic impact on
program performance, even in VB6 and earlier.

This assumes that ASP.NET is strongly typed (it wasn't in earlier releases).

--
Good judgment comes from experience.
Experience comes from bad judgment.

http://www.acadx.com


"Beginner" <a@b.com> wrote in message news:3c1665a3$1@147.208.176.211...
>
> On page 1258 of Professional ASP.NET, Scott Guthrie says Option Strict
"can
> provide better performance" but doesn't say why (or how much). Can anyone
> explain *why* Option Strict makes indentical code run faster?

Are you saying that with Option Strict Off, the VB compiler will wrap every
type with some sort of wrapper to ensure types are the same? For example,
let's say I have this code snippet:

Dim a As Integer
Dim b As Integer
a = b

If I have add an Option Strict On to the top of this module, it will magically
run faster?

"Bob Butler" <butlerbob@earthlink.net> wrote:
>
>"Beginner" <a@b.com> wrote in message news:3c167804$1@147.208.176.211...
>>
>> AFAIK, early vs. latebinding and strict-type vs loose type checking are
>two
>> different things.
>>
>
>They are, but on another level it's the same basic issue. In one case the
>compiler can resolve all ambiguities and output code to handle the specific
>situation while in the other case the compiled code has to examine the
>arguments at runtime and determine how to handle it.

Admittedly, I've never used the IL decompiler until now, but I fired it up
and decompiled the below code with both Option Strict On and Off. Unless
I did something wrong, there is no difference in the resulting IL.

"Beginner" <a@b.c> wrote:
>
>For example,
>let's say I have this code snippet:
>
>Dim a As Integer
>Dim b As Integer
>a = b
>
>If I have add an Option Strict On to the top of this module, it will magically
>run faster?

"Beginner" <a@b.com> wrote in message news:3c167804$1@147.208.176.211...
>
> AFAIK, early vs. latebinding and strict-type vs loose type checking are
two
> different things.
>

They are, but on another level it's the same basic issue. In one case the
compiler can resolve all ambiguities and output code to handle the specific
situation while in the other case the compiled code has to examine the
arguments at runtime and determine how to handle it.

"Beginner" <a@b.c> wrote in message news:3c168a12$1@147.208.176.211...
>
> Are you saying that with Option Strict Off, the VB compiler will wrap
every
> type with some sort of wrapper to ensure types are the same? For example,
> let's say I have this code snippet:
>
> Dim a As Integer
> Dim b As Integer
> a = b
>
> If I have add an Option Strict On to the top of this module, it will
magically
> run faster?

No, I was making an assumption that the code would be using variants and/or
using code where implicit conversions would have to take place. I haven't
looked at the IL but I wouldn't expect typed variables to be handled
differently, just that Option Strict forces you to use them and to
explicitly handle any conversions needed.

I ran another test. This time, I changed the variable ‘a’ to a Short which
requires a cast. I made three different versions:

1) option strict off, implicit conversion
2) option strict off, explicit conversion
3) option strict on, explicit conversion

Here’s the code:

'1) option strict off, implicit conversion
Option Strict Off
Module Module1

Sub Main()
Dim a As Short
Dim b As Integer
a = b
End Sub

End Module

'2) option strict off, explicit conversion
Option Strict Off
Module Module1

Sub Main()
Dim a As Short
Dim b As Integer
a = CShort(b)
End Sub

End Module

'3) option strict on, explicit conversion
Option Strict On

Module Module1

Sub Main()
Dim a As Short
Dim b As Integer
a = CShort(b)
End Sub

End Module

I disassembled all three versions. 1) and 2) were identical:

.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = (
01 00 00 00 )
// Code size 6 (0x6)
.maxstack 1
.locals init (int16 V_0,
int32 V_1)
IL_0000: nop
IL_0001: ldloc.1
IL_0002: conv.ovf.i2
IL_0003: stloc.0
IL_0004: nop
IL_0005: ret
} // end of method Module1::Main

Version 3 was identical except for the 7th and 8th lines:

.locals init ([0] int16 a,
[1] int32 b)

This looks like where the two variables are declared, but I’m not sure what
this means. Perhaps this is related to the performance increase Scott Guthrie
was referring to?

Beginner,
As you found out, in your example there is no difference.

I'm really not sure if its 'faster', however it is safer. You will get a
compile error when you do something unexpected as oppose to having the
runtime quietly coerce something or fail...

Dim a As Integer
Dim s As String

a = s

With Option Strict On, this will fail to compile, with Option Strict Off,
VB.NET will do the conversion for you... Possibly slower than:

a = Integer.Parse(s)

As it may inject code to check for the type, then again it may not... (I
have not looked at the IL).

Hope this helps
Jay


"Beginner" <a@b.c> wrote in message news:3c168a12$1@147.208.176.211...
>
> Are you saying that with Option Strict Off, the VB compiler will wrap
every
> type with some sort of wrapper to ensure types are the same? For example,
> let's say I have this code snippet:
>
> Dim a As Integer
> Dim b As Integer
> a = b
>
> If I have add an Option Strict On to the top of this module, it will
magically
> run faster?
>
> "Bob Butler" <butlerbob@earthlink.net> wrote:
> >
> >"Beginner" <a@b.com> wrote in message news:3c167804$1@147.208.176.211...
> >>
> >> AFAIK, early vs. latebinding and strict-type vs loose type checking are
> >two
> >> different things.
> >>
> >
> >They are, but on another level it's the same basic issue. In one case
the
> >compiler can resolve all ambiguities and output code to handle the
specific
> >situation while in the other case the compiled code has to examine the
> >arguments at runtime and determine how to handle it.
>

Beginner,

Options Strict gives you a performance gain because you are forced to
explicitly define the conversion type, by doing so the runtime system does
not have to evaluate the variable (object) to first determine what it's type
is, that's where the performance gain comes.

It's not so much that "Option Strict" in and of itself gives the peformance
gain, it's just the fact of explicitly defining the conversion type ahead of
time. If you are careful enough it's possible to explicitly define all your
conversion types without using the "Option Strict" statement, However we
would probably miss some of the more indiscrete conversions that are
occuring without us noticing it.

As Bob indicated the issue is somewhat similar to that of early vs. late
binding. It's a matter of how much prep work the system has to do before it
actually carries out the instruction.

Cecilio Thomas


"Frank Oquendo" <franko@acadx.com> wrote in message
news:3c166a89@147.208.176.211...
> Because Option Strict forces you to identify all data types at compile
time,
> not run time. Eliminating late binding has always had a dramatic impact on
> program performance, even in VB6 and earlier.
>
> This assumes that ASP.NET is strongly typed (it wasn't in earlier
releases).
>
> --
> Good judgment comes from experience.
> Experience comes from bad judgment.
>
> http://www.acadx.com
>
>
> "Beginner" <a@b.com> wrote in message news:3c1665a3$1@147.208.176.211...
> >
> > On page 1258 of Professional ASP.NET, Scott Guthrie says Option Strict
> "can
> > provide better performance" but doesn't say why (or how much). Can
anyone
> > explain *why* Option Strict makes indentical code run faster?
>
>

"Cecilio Thomas" <cecilio_thomas@hotmail.com> wrote:
>
>It's not so much that "Option Strict" in and of itself gives the peformance
>gain, it's just the fact of explicitly defining the conversion type ahead
of
>time.

I thought of this as a possible explanation. If this is true, then Guthrie's
statement is misleading if not technically wrong. Even still, in the code
sample I provided where an Integer is assigned to a Short, I don't see any
reason why the compiler can't figure out the cast at compile time. There
shouldn't be any runtime overhead.

OTOH, when I disassembled the code in my previous posts, there was a slight
change on lines 7 and 8 when turning on Option Strict. Unfortunately, I don't
really know IL so I can't say if this change is significant.

> OTOH, when I disassembled the code in my previous posts, there was a
slight
> change on lines 7 and 8 when turning on Option Strict. Unfortunately, I
don't
> really know IL so I can't say if this change is significant.

Have you tried something similar with your own classes instead of integers?
Integers may be a little different since, AFAIK, the whole type casting
thing is to ensure that there isn't an overflow and you are aware of what
you are doing. A custom class where you aren't doing the type casting may be
a little different. I am curious to see what the IL would look like in that
case.

Cal

"Cali LaFollett" <cali@no-spam-please-visionized.com> wrote
>
> Have you tried something similar with your own classes instead of integers?
> Integers may be a little different since, AFAIK, the whole type casting
> thing is to ensure that there isn't an overflow and you are aware of what
> you are doing. A custom class where you aren't doing the type casting may be
> a little different. I am curious to see what the IL would look like in that
> case.

Perhaps this will help fill in a few gaps....

I used two cases that trip up when Option Strict is on;

Private Sub Form1_Load(...) Handles MyBase.Load
Dim a As Boolean
'a = 1
a = CBool(1)
End Sub

Private Sub Form1_Click(ByVal sender As Object, ...) Handles MyBase.Click
Dim Text As String
'Text = sender.Text
Text = CType(sender, Form).Text
End Sub


In Form_Load there was no difference between using either expression:

Private Sub Form1_Load(...) Handles MyBase.Load
00000000 push ebp
00000001 mov ebp,esp
00000003 sub esp,0Ch
00000006 mov dword ptr [ebp-4],ecx
00000009 mov dword ptr [ebp-8],edx
0000000c xor eax,eax
0000000e nop
a = CBool(1)
0000000f mov eax,1
End Sub

The above shows line 0x000f as the one ML instruction used for the
assignment command. It is the same line used when a = 1 is disassembled.

In Form_Click there was a difference:

Strict Off

Private Sub Form1_Click(...) Handles MyBase.Click
00000000 push ebp
00000001 mov ebp,esp
00000003 sub esp,0Ch
00000006 push edi
00000007 push esi
00000008 mov dword ptr [ebp-4],ecx
0000000b mov esi,edx
0000000d xor edi,edi
0000000f nop
Text = sender.Text
00000010 push dword ptr ds:[01B103FCh]
00000016 xor edx,edx
00000018 mov ecx,2CB6B2Eh
0000001d call FD1FB934
00000022 push eax
00000023 push 0
00000025 mov ecx,esi
00000027 xor edx,edx
00000029 call dword ptr ds:[035B6F44h]
0000002f mov ecx,eax
00000031 call dword ptr ds:[035B7170h]
00000037 mov edi,eax
End Sub


Strict On

Private Sub Form1_Click(...) Handles MyBase.Click
00000000 push ebp
00000001 mov ebp,esp
00000003 sub esp,0Ch
00000006 push edi
00000007 push esi
00000008 mov dword ptr [ebp-4],ecx
0000000b mov esi,edx
0000000d xor edi,edi
0000000f nop
Text = CType(sender, Form).Text
00000010 mov edx,esi
00000012 mov ecx,2E84518h
00000017 call 5D4D92CE
0000001c mov ecx,eax
0000001e mov eax,dword ptr [ecx]
00000020 call dword ptr [eax+000000D8h]
00000026 mov edi,eax
End Sub

To keep those EULA lawyers from crowding in, this is not a benchmark comparison.
It is validating evidence that in this case, using Option Strict helps to remove VB.Net's
own compiler conversion routines.

Maybe not so surprizingly, the difference amounts to one extra call, and a handfull of
additional instructions, if you opt to run with Strict Off. My opinion would be that it
really wouldn't be a speed performance issue anywhere other than in some forms
of critical code.

YMMV
LFS

> To keep those EULA lawyers from crowding in, this is not a benchmark
comparison.
> It is validating evidence that in this case, using Option Strict helps to
remove VB.Net's
> own compiler conversion routines.
>
> Maybe not so surprizingly, the difference amounts to one extra call, and a
handfull of
> additional instructions, if you opt to run with Strict Off. My opinion
would be that it
> really wouldn't be a speed performance issue anywhere other than in some
forms
> of critical code.

Larry,

Your results appeared similar to what I was expecting. Those few extras are
enough to convince me that I want to keep option strict on. I just feel a
little safer that way, kinda like a bug in a rug. ;-) The only thing that
does kinda suck is having to cast numeric types all the time. Oh well, gives
my fingers practice.

Thanks again,

Cal

If you explicitly cast your code, Option Strict On won't generate different
code from having Option Strict Off (that I know of).

> .locals init (int16 V_0,
> int32 V_1)

>Version 3 was identical except for the 7th and 8th lines:
>
>.locals init ([0] int16 a,
> [1] int32 b)
>
>This looks like where the two variables are declared, but I’m not sure what
>this means. Perhaps this is related to the performance increase Scott Guthrie
>was referring to?

".locals init" is the ILDasm representation of slot allocation (local variable
declaration and allocation).

I take it the difference you are referring to is that in one, you see something
like "V_0" and "V_1" whereas in the other it's "[0]" and "[1]". All local
slots are referred to by ordinal (a number), so your first variable is variable
"0", the next one is variable "1" and so on. I'm not absolutely positive,
but I've seen the vb compiler spit the "V_n" representation when no debug
info is present, and "[n]" when debug info is provided. This has nothing
to do with Option Strict as far as I know.

-Rob

Hi Larry,

Just a couple of points to clarify. The code in the Form_Load procedure should
be the same in both cases. The reason for this is simple. A constant of value 1
is being assigned to a boolean. This is evaluated at compile time to a simple
assignment for the boolean of True, as 1 <> 0.

In the second snippet of code, the Form1_Click procedure, there are different
operations being performed. If you think logically about what the compiler must
do in the two cases, the difference should be apparent.

For the strict off code, Text = sender.Text, the compiler has to get the type
information for the object at runtime and attempt to access a "Text" member of
the object. It has no information as to what the "Text" member is, a field, a
method or property. It also has no information as to the return type of the
object's "Text" member.

For the strict code, Text = Ctype(sender,Form).Text, then the compiler jsut
simply has to issue a cast to see if the sender is of the type Form. This get's
resolved at runtime. However, if it is, then the Text property can be resolved
to a call to the Form type's Text property get method. As this method is a
virtual method, there is still some more runtime resolving going on here. The
assignemnt to a string however can be validated at compile time based on the
Form's type information.

So both the option strict on and option strict off code in this exampel do have
late bound calls going on. Jsut in the option strict off case it has all the
late bound calls the strict on code has to have, but it alsoi has a lot, one
**** of a lot more.


"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3c1785f6@147.208.176.211...
>
> "Cali LaFollett" <cali@no-spam-please-visionized.com> wrote
> >
> > Have you tried something similar with your own classes instead of integers?
> > Integers may be a little different since, AFAIK, the whole type casting
> > thing is to ensure that there isn't an overflow and you are aware of what
> > you are doing. A custom class where you aren't doing the type casting may be
> > a little different. I am curious to see what the IL would look like in that
> > case.
>
> Perhaps this will help fill in a few gaps....
>
> I used two cases that trip up when Option Strict is on;
>
> Private Sub Form1_Load(...) Handles MyBase.Load
> Dim a As Boolean
> 'a = 1
> a = CBool(1)
> End Sub
>
> Private Sub Form1_Click(ByVal sender As Object, ...) Handles MyBase.Click
> Dim Text As String
> 'Text = sender.Text
> Text = CType(sender, Form).Text
> End Sub
>
>
> In Form_Load there was no difference between using either expression:
>
> Private Sub Form1_Load(...) Handles MyBase.Load
> 00000000 push ebp
> 00000001 mov ebp,esp
> 00000003 sub esp,0Ch
> 00000006 mov dword ptr [ebp-4],ecx
> 00000009 mov dword ptr [ebp-8],edx
> 0000000c xor eax,eax
> 0000000e nop
> a = CBool(1)
> 0000000f mov eax,1
> End Sub
>
> The above shows line 0x000f as the one ML instruction used for the
> assignment command. It is the same line used when a = 1 is disassembled.
>
> In Form_Click there was a difference:
>
> Strict Off
>
> Private Sub Form1_Click(...) Handles MyBase.Click
> 00000000 push ebp
> 00000001 mov ebp,esp
> 00000003 sub esp,0Ch
> 00000006 push edi
> 00000007 push esi
> 00000008 mov dword ptr [ebp-4],ecx
> 0000000b mov esi,edx
> 0000000d xor edi,edi
> 0000000f nop
> Text = sender.Text
> 00000010 push dword ptr ds:[01B103FCh]
> 00000016 xor edx,edx
> 00000018 mov ecx,2CB6B2Eh
> 0000001d call FD1FB934
> 00000022 push eax
> 00000023 push 0
> 00000025 mov ecx,esi
> 00000027 xor edx,edx
> 00000029 call dword ptr ds:[035B6F44h]
> 0000002f mov ecx,eax
> 00000031 call dword ptr ds:[035B7170h]
> 00000037 mov edi,eax
> End Sub
>
>
> Strict On
>
> Private Sub Form1_Click(...) Handles MyBase.Click
> 00000000 push ebp
> 00000001 mov ebp,esp
> 00000003 sub esp,0Ch
> 00000006 push edi
> 00000007 push esi
> 00000008 mov dword ptr [ebp-4],ecx
> 0000000b mov esi,edx
> 0000000d xor edi,edi
> 0000000f nop
> Text = CType(sender, Form).Text
> 00000010 mov edx,esi
> 00000012 mov ecx,2E84518h
> 00000017 call 5D4D92CE
> 0000001c mov ecx,eax
> 0000001e mov eax,dword ptr [ecx]
> 00000020 call dword ptr [eax+000000D8h]
> 00000026 mov edi,eax
> End Sub
>
> To keep those EULA lawyers from crowding in, this is not a benchmark
comparison.
> It is validating evidence that in this case, using Option Strict helps to
remove VB.Net's
> own compiler conversion routines.
>
> Maybe not so surprizingly, the difference amounts to one extra call, and a
handfull of
> additional instructions, if you opt to run with Strict Off. My opinion would
be that it
> really wouldn't be a speed performance issue anywhere other than in some forms
> of critical code.
>
> YMMV
> LFS
>
>
>
>
>
>
>

"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote
>
> In the second snippet of code, the Form1_Click procedure, there are different
> operations being performed. If you think logically about what the compiler must
> do in the two cases, the difference should be apparent.

Yes, even at the ML level, just one simple little call can bring a lot more code into
the picture. But, as in this case, there is a little bit of room when responding to
user events. Thanks for the clarification though, I'm glad you offered a bit of your
own expertise. If you want to say there is a speed concern, I'll just shut up, and
see which style I'm more comfortable with....

FWIW, I did leave myself a little wiggle room:

> > YMMV

<g>
LFS