[2005] Option Strict - Program Speed

Hi all,

No question, but a comment.

I spent most of today helping a guy with some possible mechanisms to speed up an application he wrote. We covered all manner of potential improvements from the way that data is stored, faster sorting algorithms, nifty file handling etc.

Having spent all day discussing it, we opened up his code to check a few things and the very first thing I noticed was Option Strict Off :eek: . So after kicking him hard where it hurts ;) , I had him switch it on and spend time cleaning up the errors. Having done that, the app now runs like a bat out of hell. So as far as I'm concerned, a whole day wasted.

So if you're writing apps, please switch Option Strict On! It can be a pain at first, but after you've cleaned up the errors, it makes life easier, not more difficult. Note my use of the word 'errors' here, IMHO Option Strict Off is a mechanism that allows errors and results in some weird and hard to find bugs. It also slows down your app due to non-optimal type conversions.

If anyone knows any good reasons why this option should ever be switched off, then please let me know.

the reason option strict can make things faster is because you are already telling the compiler what type of data to convert things to in your code. When option strict is off, it lets you assign things like integers to a string, and the framework has to do a little figuring out on the fly to cast types around.

Also try to use DirectCast() where you can versus CType(), DirectCast is more explicit that CType() and generally results in better performance.

From MSDN

Quote:

---

DirectCast does not use the Visual Basic run-time helper routines for conversion, so it can provide somewhat better performance than CType when converting to and from data type Object.

---

Quote:

---

Originally Posted by Bulldog

If anyone knows any good reasons why this option should ever be switched off, then please let me know.

---

When converting a LARGE application from VB6 to .NET, it can help a lot to turn option strict off to speed up the conversion process.

Since option strict can be turned on/off at the module level, you can turn it on in each .vb file one at a time, and clean up code that way.

For any new .NET projects I would always suggest having it on, and I think MS should have it on by default.

Indeed :thumb:

The only valid reason that I can think of to have Option Strict turned Off in new code is to allow late-binding. In some situations that's essential. In that case you should have it turned On for the project and only turn it Off in the files where late-binding is required. Anywhere that late-binding is not specifically required should have Option Strict turned On

Allowing late binding would be the main reason I can think of although using interfaces can get you around this necessity in many cases.

It's also a good idea to use Option Strict if you're overloading methods. If the types in the call can be converted to the wrong type it might cause some odd things to happen in your program.