|
-
Jun 20th, 2007, 07:17 PM
#1
Confession of an Option Strict Convert
Back when I first got going with .NET, one of the first programs I wrote was actually a program I had written in VB6, then converted over to .NET (not using any wizard, it was a total re-design).
The program is a complicated genetic algorithm that does pattern matching. The number of generations is so high that the total runtime to reach an endpoint for all tests I performed with that original version took a minimum of three days, and some took a fourth day.
A couple days back, I decided to add a feature to the program, and as I was working on it, I realized that I was not getting warnings or errors when I should have. When I looked at the project settings I found out that I had not had Option Strict On for the project. Therefore, I turned it on, and took about an hour fixing the errors that arose. All but about two of them were really trivial cases of explicitly converting things that had previously been handled implicitly. The other two were bugs that I had never encountered, but which could have caused trouble at times (in fact, the program did cause unhandled errors once every week, or so, which was too rare and random to even attempt debugging).
Having made that change, I decided to re-run the program on the same data sets that I used the first time around. Since the time to completion changes each time, no single comparison is necessarily meaningful, unless the difference in runtime was HUGE Since the change I had made added a few minor steps, but added them at the innermost loop, so that they happened ALWAYS and OFTEN, I felt that the change would be a minor increase in time taken.
Now, the first run is nearing completion, and it will finish after only two days. Considering that ALL previous runs took AT LEAST three days, this is MUCH faster than any earlier run, even with the increased operations of the new feature (and running it for a few hours in a slower mode).
Therefore, it appears that Option Strict On does not just find some bugs, it can have a highly significant affect on the runtime of a code-intensive program. All of this speed increase appears to be due solely to explicitly directing casts instead of allowing them to be implicitly handled.
Use Option Strict at ALL times.
My usual boring signature: Nothing
 
-
Jun 20th, 2007, 07:52 PM
#2
Re: Confession of an Option Strict Convert
Good post and good advice.
-
Jun 20th, 2007, 09:12 PM
#3
Re: Confession of an Option Strict Convert
Option Explicit and Option Strict should not be optional. There is always a way to convert, cast or reflect to get it working correctly.
VB/Office Guru™ (AKA: Gangsta Yoda™ ®)
I dont answer coding questions via PM. Please post a thread in the appropriate forum. 
Microsoft MVP 2006-2011
Office Development FAQ (C#, VB.NET, VB 6, VBA)
Senior Jedi Software Engineer MCP (VB 6 & .NET), BSEE, CET
If a post has helped you then Please Rate it! 
• Reps & Rating Posts • VS.NET on Vista • Multiple .NET Framework Versions • Office Primary Interop Assemblies • VB/Office Guru™ Word SpellChecker™.NET • VB/Office Guru™ Word SpellChecker™ VB6 • VB.NET Attributes Ex. • Outlook Global Address List • API Viewer utility • .NET API Viewer Utility •
System: Intel i7 6850K, Geforce GTX1060, Samsung M.2 1 TB & SATA 500 GB, 32 GBs DDR4 3300 Quad Channel RAM, 2 Viewsonic 24" LCDs, Windows 10, Office 2016, VS 2019, VB6 SP6 
-
Jun 20th, 2007, 09:23 PM
#4
Re: Confession of an Option Strict Convert
It is somewhat disappointing that Microsoft chose to have Option Strict Off by default. How many people have been developing for months or longer before they even know it exists? By then they are in bad habits and have lots of code to fix if they want to turn it On. I was in that very position myself. Having it On by default with the option to turn it Off would have been preferable, but I guess they figured that people who didn't know it existed would then be complaining that it was too hard to understand how to cast and convert all the time. I guess it's just a part of how VB is easier to use but easier to write bad code in too.
-
Jun 20th, 2007, 09:45 PM
#5
Re: Confession of an Option Strict Convert
 Originally Posted by jmcilhinney
It is somewhat disappointing that Microsoft chose to have Option Strict Off by default. How many people have been developing for months or longer before they even know it exists? By then they are in bad habits and have lots of code to fix if they want to turn it On. I was in that very position myself. Having it On by default with the option to turn it Off would have been preferable, but I guess they figured that people who didn't know it existed would then be complaining that it was too hard to understand how to cast and convert all the time. I guess it's just a part of how VB is easier to use but easier to write bad code in too.
I totally agree!
Back in VB6, Option Explicit was not the default (or was it VB5?). That was bad back then. Option Strict should be the default for .NET. I was hesitant to move there at first, because it seemed like more work. It isn't much more work, and it produces better, cleaner, safer code. Now I can see the performance benefit as well. I knew there would be some, but I didn't think it would be so great that even with the added work in the inner loop, my speed increased dramatically.
It's good to see an improvement in action, so I figured I ought to share in the hopes that somebody will be converted to using Option Strict just because of the performance consideration.
My usual boring signature: Nothing
 
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|