VB.Net CType vs. Convert & C# Casting vs. Convert

[Logan X via .NET 247]

It's official....Convert blows.

I ran a number of tests converting a double to an integer usingboth Convert & CType. I *ASSUMED* that CType would piggy-back ontop of Convert, and that performance would be identical.

I was 100% incorrect.

The code below produces the results:
CType Took: 0.2187528 seconds.
Convert Took: 12.187656 seconds.

Option Explicit On
Option Strict On

Module ConversionTest

Private Const STORED_VALUE As Double = 100000000
Sub Main()

TestCType()
TestConvert()

Console.ReadLine()
End Sub

Private Sub TestCType()
Dim l_Time As Long = 0
Dim l_Converted As Integer = 0

l_Time = DateTime.Now.Ticks
For l_LoopCounter As Integer = 0 To 100000000
l_Converted = CType(STORED_VALUE, Integer)
Next
l_Time = DateTime.Now.Ticks - l_Time
Console.WriteLine("Took " & (l_Time / 10000000) & "seconds.")

End Sub
Private Sub TestConvert()
Dim l_Time As Long = 0
Dim l_Converted As Integer = 0

l_Time = DateTime.Now.Ticks
For l_LoopCounter As Integer = 0 To 100000000
l_Converted = Convert.ToInt32(STORED_VALUE)
Next
l_Time = DateTime.Now.Ticks - l_Time
Console.WriteLine("Took " & (l_Time / 10000000) & "seconds.")
End Sub

End Module

The IL is VERY different. It appears as though the Convert iscreating a local copy of the Const variable per loop. Is thiscorrect? Does Convert take into account globalization? (Thatwould certainly explain the delay) If you change the conversionto act against the l_LoopCounter then the performance differencenarrows substantially, BUT Convert is still far behind.

It seems that in *ALL* cases, CType > Convert. (This *ALSO* holdstrue in C#.)

Thank you.
--------------------------------
From: Logan X

-----------------------
Posted by a user from .NET 247 (http://www.dotnet247.com/)

<Id>F4QPoBi5CkGScnFqZ4CGOw==</Id>

[Jon Skeet [C# MVP]]

Logan X via .NET 247 <an*******@dotnet247.com> wrote:

It's official....Convert blows.

I ran a number of tests converting a double to an integer using both
Convert & CType. I *ASSUMED* that CType would piggy-back on top of
Convert, and that performance would be identical.

They're doing different things though. For example, Convert.ToInt32
performs bankers rounding, whereas casting truncates towards 0. Here's
an example:

using System;

class Test
{
static void Main()
{
Show(0.5);
Show(1.5);
Show(-0.5);
Show(-1.5);
}

static void Show (double d)
{
Console.WriteLine ("{0}\t{1}\t{2}",
d, (int)d, Convert.ToInt32(d));
}
}

Bankers rounding requires actual calculations, as opposed to truncation
which I suspect can be done in a single processor instruction. (Haven't
checked that, but I suspect it can.)

Convert.ToInt32 also always detects overflow and throws an exception if
it occurs.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Logan X via .NET 247 <an*******@dotnet247.com> wrote:

It's official....Convert blows.

I ran a number of tests converting a double to an integer using both
Convert & CType. I *ASSUMED* that CType would piggy-back on top of
Convert, and that performance would be identical.

They're doing different things though. For example, Convert.ToInt32
performs bankers rounding, whereas casting truncates towards 0. Here's
an example:

using System;

class Test
{
static void Main()
{
Show(0.5);
Show(1.5);
Show(-0.5);
Show(-1.5);
}

static void Show (double d)
{
Console.WriteLine ("{0}\t{1}\t{2}",
d, (int)d, Convert.ToInt32(d));
}
}

Bankers rounding requires actual calculations, as opposed to truncation
which I suspect can be done in a single processor instruction. (Haven't
checked that, but I suspect it can.)

Convert.ToInt32 also always detects overflow and throws an exception if
it occurs.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too