VB Conversion Keywords And .NET Conversion Routines -- dotnet performance

Dennis
2/28/2005 6:19:03 PM

Don't you think that the compiler compiles Cint function to basically the
same as Convert.ToInteger32? I really wonder if Cint function calls
convert.ToInteger32. Are you positive about this?

[quoted text, click to view]

rawCoder
2/28/2005 8:14:56 PM

Hi,

Just wanted to know if there is any speed difference between

VB conversion Keywords like CInt, Clng, CStr, CDbl, CBool etc.
..NETs Convert.To<...> methods.

And which is better to be used and why ?

Thanx
rawCoder

Bob Grommes
2/28/2005 9:53:52 PM

Dennis,

I am accustomed to using the static Convert methods in C# and my most
extensive legacy VB experience was with ASP/VBScript, where I found the
various intrinsic conversion functions rather overly "helpful" and sometimes
just plain strange (e.g., banker's rounding). Moving back and forth between
VB.NET and C#, I find that consistency and predictabiliy to be something I
value. Your mileage, and your priorities, may vary.

Regarding CInt() specifically, one of the links provided by another posted
in this thread concedes that for example CInt(string) is "slightly" slower
than Convert.ToInt32(string) but that CInt(long) would be faster than
Convert.ToInt32(long) because CInt(long) compiles directly to a single IL
instruction. So it looks like performance differences vary in both
directions and perhaps it is just down to a combination of personal
preference and habit after all.

--Bob

[quoted text, click to view]

guy
2/28/2005 11:09:03 PM

[quoted text, click to view]
***
Why?
CInt is more readable and requires less typing (always a plus for me!) than
CType
and remember, the less you type the less bugs you get
***
[quoted text, click to view]

Scott M.
3/1/2005 12:37:17 AM

Where do CType and DirectCast fit into this? I know that DirectCast is more
efficient than CType when it can be used, but isn't the single use of CType
easier and more consistent than the various CInt, Cstr, CBool, CDbl, etc.
functions?

[quoted text, click to view]

Cor Ligthert
3/1/2005 8:29:04 AM

Scott,

In other words

The DirectCast "Take as"
The CType "Convert to"

Cor

Cor Ligthert
3/1/2005 8:46:13 AM

Bob,
[quoted text, click to view]

What is not true I tested it yesterday (I deleted the test already) and the
figurs where 2:1 however that in a processing time which does in my opinion
in a normal 80:20 optimizing situation not has the influence real to think
about.

Cor

Jay B. Harlow [MVP - Outlook]
3/1/2005 9:21:30 AM

rawCoder,
[quoted text, click to view]
In case you missed it:

www.panopticoncentral.net is Paul Vick's blog, Paul Vick is the Technical
Lead of the Visual Basic.NET Development team at Microsoft, here is his
thoughts:

http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx

Hope this helps
Jay

[quoted text, click to view]

Bob Grommes
3/1/2005 9:36:11 AM

I'm given to understand that CType() itself is in fact equivalent to the
corresponding Convert methods, and that DirectCast is about the same as a C#
cast, which is faster since it's a cast rather than a conversion.

In reality I'm not sure that we're doing anything but splitting hairs here
though ... this conversation is interesting but ultimately, in real world
line of business scenarios, the differences in performance are not that
significant. If we were doing matrix math or image manipulation, it might
matter. But if we're simply unboxing datarow values and converting textbox
strings to integer or decimal, and other *typical* operations, it probably
doesn't in fact matter how you accomplish it, from a performance
perspective. So I go for consistency and use metaphors that would be
familiar to any developer who knows the .NET framework, regardless of their
language experience.

--Bob

[quoted text, click to view]

Bob Grommes
3/1/2005 9:42:42 AM

Whoops, that was misinformation, I misread an article -- CType() is exactly
equivalent to the corresponding intrinsic VB functions (CInt, etc) not to
Convert methods.

[quoted text, click to view]

Scott M.
3/1/2005 10:17:34 AM

Well, I don't necessarily agree, in that with CType, there is just one
function to use. Rather than the 5 or 6 legacy conversion functions. I
find CType to be more consistent.

[quoted text, click to view]

Scott M.
3/1/2005 10:18:51 AM

That doesn't really address my question Cor. My question was what (if any)
advantage is there to using CInt or Convert.ToInt16 over CType or
DirectCast?

[quoted text, click to view]

D._André_Dhondt
3/1/2005 10:27:10 AM

[quoted text, click to view]
Set up a loop to do these conversions 10,000 times and test each method
5 or so times (cause a timed loop could be affected by background

Jay B. Harlow [MVP - Outlook]
3/1/2005 10:31:24 AM

Scott,
Paul's blog indicates that CInt() is an alias for CType(, Integer).

As Cor suggests CType is the conversion operator, while DirectCast is the
cast operator.

To "confuse" the issue the Conversion operator can be used as the cast
operator, however I make every effort to avoid this, as VS.NET 2005 allows
operator overloading! With operator overloading we can use the Conversion
operator (CType) to convert our types as needed.

http://msdn2.microsoft.com/library/yf7b9sy7.aspx

For example we can define the conversion for a Rational (Fraction) type to &
from Double. Where the Rational type holds the Numerator & Denominator as
separate fields. CType will be able to use the overloaded conversion
operators, while I understand that Convert.To* will not.

Public Structure Rational

Private m_numerator As Integer
Private m_denominator As Integer

Public Shared Widening Operator CType(ByVal f As Rational) As Double
Return f.m_numerator / f.denominator
End Operator

Public Shared Narrowing Operator CType(ByVal d As Double) As Rational
Return New Rational(d)
End Operator

End Structure

Dim f As Fraction
Dim d As Double

f = CType(d, Fraction)
d = f

Hope this helps
Jay

[quoted text, click to view]

Scott M.
3/1/2005 12:14:02 PM

So what then is the difference between CType and the Convert methods?

[quoted text, click to view]

Daniel Moth
3/1/2005 12:15:27 PM

If you know the datatype matches your target then you are after a cast so
use DirectCast. Nobody will disagree with that (famous last words :)

If you want to do a conversion then you have two choices:
1. Convert.ToXXX
or
2. the VB conversions (whether you go with CInt, CBool etc or with CType is
down to coding preference, end of story)

The performance difference between the two does not justify using one over
the other so it comes down to preference again. The advice is to stop
looking at it as a performance thing and choose based on your team's coding
standards (consistency is more important).

My *personal* preference is always 1. It makes converting code from one
language to the other easier and since I work in both languages it makes
reading code easier too. Your requirements may vary.

Cheers
Daniel
--
http://www.danielmoth.com/Blog/

[quoted text, click to view]

Herfried K. Wagner [MVP]
3/1/2005 12:36:04 PM

"Scott M." <s-mar@nospam.nospam> schrieb:
[quoted text, click to view]

For reference types the compiler will create the exact same IL for both,
'CType' and 'DirectCast', so the performance is equal. I prefer
'DirectCast' in this case to make it more obvoius that only a type cast is
going on and not a type conversion.

[quoted text, click to view]

'CType(Foo, Integer)' compiles to the same IL as 'CInt(...)' does. I think
that 'CInt', 'CStr', etc. are far better readable than 'CType(..., ...)'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Cor Ligthert
3/1/2005 1:44:15 PM

RawCoder,

You will by the team than probably be directed too this page

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchmicrosoftvisualbasicnetinternals.asp

In the section
Conversion Functions, CType, DirectCast, and System.Convert
Maybe you can read it allready before

:-)

Cor

Scott M.
3/1/2005 1:51:13 PM

Well, I thought that I did explain why I prefer not to use them. I prefer
the consistency of CType, rather than the various C* functions. In my mind,
the many C* functions have been replaced by just one function to deal with.
In that sense, I can't imagine why anyone would want to use the various C*
functions.

[quoted text, click to view]

Bob Grommes
3/1/2005 2:14:44 PM

"Legacy" is a matter of perspective. The C*() functions are not legacy VB
functions in the sense that they have been deprecated in the VB language,
but if you take a larger view from a .NET perspective, they are legacy
functions in that they duplicate .NET framework functionality for the sake
of backward compatibility support of a non .NET language. The C*()
functions have no reason to exist other than that, and in that sense they
make VB.NET needlessly different with a divergent syntax and in some cases,
different behaviors or responses to boundary conditions.

If you are developing in other .NET languages as well as VB.NET, the C*()
functions seem much more superfluous than if you come from a VB6 background
and are mostly focused on developing in VB.NET.

Mind you, I'm not asking you to agree or disagree, just to understand that
there are other points of view, and they have validity depending on your
perspective and approach.

--Bob

[quoted text, click to view]

Bob Grommes
3/1/2005 2:25:26 PM

[quoted text, click to view]

The URLs that have been provided elsewhere in this thread explain it better
than I can, but basically, the Convert methods are the way the framework
expects conversions to happen. For example, Convert.ToInt32("2.5") is an
error, whereas CInt("2.5") or CType("2.5",Integer) is not. Furthermore,
CInt("2.5") yields 2 (banker's rounding) whereas Math.Round(2.5,0) yields 3.
I'm sure there are other examples. Personally I don't want to have to
remember special rules for a particular language.

On the plus side, some kinds of calls to the C*() functions are optimized to
be very fast, faster than Convert methods. Such as CInt(someLongValue) or
CLng(someIntValue). But in practice, how often do you actually do such
conversions? In my work, almost never. In any case the consensus in this
thread, with which I now agree, is that real world performance differences
are negligible. So it's probably more important to do what you want, and do
it consistently.

--Bob

[quoted text, click to view]

Jay B. Harlow [MVP - Outlook]
3/1/2005 3:57:48 PM

Bob,
[quoted text, click to view]
They both yield 2 in both VS.NET 2002 & VS.NET 2003 (.NET 1.0 SP3 & .NET 1.1
SP1). I would be very surprised if this changed in VS.NET 2005, I do however
understand that VS.NET 2005 gives us the option to use Banker's Rounding or
not.

In fact all three (CInt, Math.Round, Convert.ToInt16) do banker's rounding
as .NET does banker's rounding.

Try the following:
Debug.WriteLine(CInt(2.5), "CInt(2.5) ")
Debug.WriteLine(CInt("2.5"), "CInt(""2.5"")")
Debug.WriteLine(Convert.ToInt32(2.5), "Convert.ToInt32(2.5)")
Debug.WriteLine(Math.Round(2.5, 0), "Round(2.5)")
Debug.WriteLine(CInt(1.5), "CInt(1.5) ")
Debug.WriteLine(CInt("1.5"), "CInt(""1.5"")")
Debug.WriteLine(Convert.ToInt32(1.5), "Convert.ToInt32(1.5)")
Debug.WriteLine(Math.Round(1.5, 0), "Round(1.5)")

Hope this helps
Jay

[quoted text, click to view]

Scott M.
3/1/2005 4:33:23 PM

I know you didn't ask for agreement or disagreement, but I wholeheartedly
agree and think that you couldn't have summed it up better Bob.

[quoted text, click to view]

Cor Ligthert
3/1/2005 4:34:11 PM

Scott,

Probably I misunderstood you.
For me is using CInt just that it are 4 letters to type instead of
CType(xx,xx) in the cases where I can use it

For the rest see this page which I sent today as answer to RawCoder as well.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchmicrosoftvisualbasicnetinternals.asp

In the section
Conversion Functions, CType, DirectCast, and System.Convert

I hope that it clears it a little bit more.

Cor

rawCoder
3/1/2005 5:00:20 PM

Thank you all for your comments.

Seems like the comments are a little diverse than i expected them to be
which might mean that the problem isnt that simple as it initially seemed to
me. I hope I aint asking for too much but can someone please summarize ( if
possible ) the differences in terms of performance and IL generation for the
followings.

Intrinsic VB Conversion Ops ( CInt, CBool, CDbl, CLng, CObj, CStr etc. )
Convert class Convert.To methods
CType method
DirectCast method

I understand that there are differences of ValueType and ReferenceType and
the datatype diffreneces also count, but there must be some flow or
checklist to identify excatly when should one use which conversion
technique..

May b someone from Visual Basic Development team might be in the best
position to tell us which IL is better

( Dim i As Integer = CInt("1") )
IL_0001: ldstr "1"
IL_0006: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
romString(string)
IL_000b: stloc.0

( Dim j As Integer = CInt("2") )
IL_000c: ldstr "2"
IL_0011: call int32 [mscorlib]System.Convert::ToInt32(string)
IL_0016: stloc.1

Thank You Again All.
rawCoder

Scott M.
3/1/2005 5:41:44 PM

Herifried, I don't think you really read my post. I'm not looking for an
[quoted text, click to view]

and I simply told you why I prefer to not use them.

[quoted text, click to view]

Scott M.
3/1/2005 5:45:03 PM

Herfried, take a deep breath. I think we are at the point in this thread
where it's pretty clear we are talking about preferences and you are trying
to "argue" your preference over others. If there was only one choice, then
there wouldn't be a need for preferences.

I say tom-A-to, you say to-MA-to.

[quoted text, click to view]

Dennis
3/1/2005 5:47:01 PM

What if in vb.Net 2007 an integer becomes 8 bytes and a double becomes 16
bytes, would not then Cint and Cdbl or Ctype maintain more consistency of
code and automatically utilize 8 byte integers as opposed to Convert.ToInt32?
In the 64bit world, this could become real confusing. Wonder how M'soft
will handle it?

[quoted text, click to view]

Herfried K. Wagner [MVP]
3/1/2005 6:40:29 PM

"Scott M." <s-mar@nospam.nospam> schrieb:
[quoted text, click to view]

Why do you think the 'C*' conversion functions are "legacy functions"? They
are part of the Visual Basic language like 'If...Then'. There is
*absolutely no* reason for not using them. Or would you try to avoid to use
'(int)x' in C# because it's "legacy"?!

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Scott M.
3/1/2005 9:54:20 PM

In depth discussion is fine and as I've said, it seems that we've played
that out as most of the last posts are now talking about how people prefer
this or that. Since the in depth discussion has pretty much resulted in a
consensus that for the most part using either syntax is equivalent, we are
now talking about preferences. If A = B then it is hard to say that A is
bad but B is good.

[quoted text, click to view]

Herfried K. Wagner [MVP]
3/1/2005 11:07:12 PM

"Scott M." <s-mar@nospam.nospam> schrieb:
[quoted text, click to view]

I prefer the readability of code that uses the various 'C*' functions :-).

[quoted text, click to view]

The 'C*' functions were not replaced. Instead, 'CType' was added to allow
explicit casting to user defined types when using strict semantics.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Herfried K. Wagner [MVP]
3/1/2005 11:14:48 PM

Bob,

"Bob Grommes" <bob@bobgrommes.com> schrieb:
[quoted text, click to view]

So '(int)', '(string)' etc. in C# are casts that should not be used because
they are included for backward compatibility reasons too? I feel sorry, but
I cannot follow this argumentation. There are /so many/ features in
VB.NET/C# that wrap around low-level features provided by the .NET
Framework. That does't make them bad features.

[quoted text, click to view]

Is 'Select Case' a legacy statement too? You could replace it by lots of
'If's. Isn't VB.NET/C# only a replacement for pure and clean MSIL?

[quoted text, click to view]

I am developing in C# too, but that /never/ lead me to think that 'CInt',
etc. are redundant. They are syntax shortcuts like the '+' operator, for
example. The can be used but there are alternatives. Nevertheless, I try
to pick the feature out of the set of semantically equivalent features that
are available by choosing the feature with the best readability and
maintainability. For me, it does not matter how easily code can be
converted to another .NET programming language, because this would reduce
productivity without adding any value.

[quoted text, click to view]

:-)

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Herfried K. Wagner [MVP]
3/2/2005 12:35:46 AM

"Scott M." <s-mar@nospam.nospam> schrieb:
[quoted text, click to view]

Well, then I don't see any reason for discussion at all.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Herfried K. Wagner [MVP]
3/2/2005 12:37:01 AM

"Scott M." <s-mar@nospam.nospam> schrieb:
[quoted text, click to view]

There are good and bad preferences. But I see, you don't like in-depth
discussion and evaluation of arguments.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Jon Skeet [C# MVP]
3/2/2005 6:41:00 AM

[quoted text, click to view]

If that's the case, it's no longer a compatible language with the
existing VB.NET, basically.

Fortunately, I don't think MS is stupid enough to do that. There's
already an integer type which is 8 bytes long, and if they need to
introduce new, larger types, they can give them new names. That way we
won't get into the message C is in.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet

Jay B. Harlow [MVP - Outlook]
3/2/2005 8:19:52 AM

Dennis
False speculation:

In VB.NET 2005 (.net 2.0) aka Whidbey due out later in 2005. Integer remains
an alias for Int32 on both the 32-bit & 64-bit versions of the runtime.
There has been long discussions on this with numerous links. If you want the
links I can look for them.

Seeing as .NET 2.0 has a 64-bit framework & didn't change why would it
change in VB.NET 2007 (.net 3.0+)?

Hope this helps
Jay

[quoted text, click to view]

Herfried K. Wagner [MVP]
3/2/2005 12:24:43 PM

"Dennis" <Dennis@discussions.microsoft.com> schrieb:
[quoted text, click to view]

The datatypes will remain in their current size, which means that an
'Integer' (= 'Int32') will /always/ be 32-bit, and 'Integer' will /always/
map to 'Int32'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Cor Ligthert
3/2/2005 2:09:55 PM

[quoted text, click to view]

Where I have understand from the documentation there would be more
posibilities in 2.0

Cor Ligthert
3/2/2005 2:29:07 PM

Bob,

There is in all program and natural languages a lot of legacy. To keep it
with the program languages how older the language the more legacy. There is
in my opinion a lot of legacy in all from C derived program languages.

To say something about your point of view; because of the fact that
Microsoft.VisualBasic is an integrated part from the framework, can you not
skip methods from that.

To give an analogy
You can say that the USA is America and in the same way that the EU is
Europe.

However, because of that is Brazil not a legacy part of America and Russia a
legacy part of Europe.

Just my thought,

Cor

Cor Ligthert
3/2/2005 3:56:04 PM

Dennis,

I thought that there are still discussions if an Intel 64Bits will be one
32Bits processor or a 2 times 32Bits processor.

A proffesional program language builder would never decide to set his
standard calculating/indexer format to another format than the most optimal
for the most used processor.

That would direct be an (easy) advantage for all is concurents when he did
not and they did.

Although I feel something for the argument from Jon (and than of course an
upgrade procedure from Integer to let say PF. (Processor Format).

It seems that Microsoft has told with the last upgrade from 16Bits Basic to
32Bits VB that they would never do that anymore. However I think that a
VBNet programmer is not a Basic 2 programmer.

Just my thought,

Cor

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet performance

dotnet performance : VB Conversion Keywords And .NET Conversion Routines