Option Strict Faster?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 17

Thread: Option Strict Faster?

  1. #1
    Beginner Guest

    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?

  2. #2
    Beginner Guest

    Re: Option Strict 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?

    >
    >



  3. #3
    Frank Oquendo Guest

    Re: Option Strict 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?




  4. #4
    Beginner Guest

    Re: Option Strict 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.



  5. #5
    Beginner Guest

    Re: Option Strict Faster?


    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?




  6. #6
    Bob Butler Guest

    Re: Option Strict 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.




  7. #7
    Bob Butler Guest

    Re: Option Strict Faster?


    "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.





  8. #8
    Beginner Guest

    Re: Option Strict Faster?


    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?



  9. #9
    Jay B. Harlow Guest

    Re: Option Strict Faster?

    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.

    >




  10. #10
    Cecilio Thomas Guest

    Re: Option Strict Faster?

    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?

    >
    >




  11. #11
    Beginner Guest

    Re: Option Strict 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.



  12. #12
    Cali LaFollett Guest

    Re: Option Strict Faster?

    > 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



  13. #13
    Larry Serflaten Guest

    Re: Option Strict Faster?


    "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








  14. #14
    Cali LaFollett Guest

    Re: Option Strict Faster?

    > 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



  15. #15
    Rob Teixeira Guest

    Re: Option Strict Faster?



    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center