Just a small post after a long time not posting (been moving between countries… it kinda takes up your spare time you know?)
Recently I have been working on a mostly VB.NET project in a more hands-on development capacity than I have been used to in recent years. Needs must when you have a family to feed - especially in the current economy.
Whilst C# is by far my preferred language to work with (hence the name of this site) with Java and C++/CLI closely following, despite my general complaints, I have been using and retaining familiarity with VB.NET over the years as it’s always a good idea to ‘know your enemy’ so to speak.
There are many reasons I don’t like VB/BASIC as a language, but at least you would hope that no matter what, the VB.NET compiler team would at least do some basic optimisation on certain operations. But it would seem that forcing integer division operations needlessly through the FPU is par for course…
This is a small peeve of mine… especially as it’s such an obvious and easy optimization.
In VB.NET, ‘CType’ is the quickest cast/conversion operation from a double to an Int32 in VB.NET the follow expression compiles to this (yes, all optimisations are ON): [NB: ! prefix = unrequired)
! ldc.r8 100 // r8 = double ==> FPU (should be ldc.i4.s)
ldarg.1
callvirt (blah..).get_Count()
! conv.r8 // r8 = double ==> FPU
div
! call float64 (blah..).Math::Round(float64) // ==> JIT to FPU instructions
! conv.i4 // this will also be a couple of FPU instructions as return value is r8
stloc.1
C# does *exactly* the same thing thus:
ldc.i4.s 100
ldarg.1
callvirt (blah..).get_Count()
div
stloc.1
Understandably the VB.NET version is ~2.2 times slower mostly due to needlessly forced FPU operations.
Funny, you would have thought this:
DirectCast(100/distroItems.Count,Int32)
would be like: (int)(100/distroItems.Count)
But the directcast operation is illegal...
Subscribe