which approach outperforms the other ?

  • Thread starter Thread starter tinman
  • Start date Start date
T

tinman

Hi...

I have the following two excerpts from a method. It basically reads data
from a DataReader and
loads it in a collection.


Excerpt A:
********
With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"), DateTime), _
DirectCast(.Item("end_date"), DateTime), _
DirectCast(.Item("priority"), Integer), _
DirectCast(.Item("description"), String), _
DirectCast(.Item("project_manager"), String)
End While
End With




Excerpt B:
********
With ProjectData
While .Read
Me.Add(.Item("project_id"),
.Item("start_date"),
.Item("end_date"),
.Item("priority"),
.Item("description"),
.Item("project_manager")
End While
End With



Question:

Does automatic casting outperform explicit casting ? When I run ILDASM, I
find
that at each DirectCast, there is unboxing but in Excerpt B, there isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
romObject(object)

Any pointers to articles that explain what goes on "under the hood" with
regards to
casting would be much appreciated as well.

Cheers !
 
This is mearly a guess at best...but I would like to learn this as well...

I would assume the direct cast would be faster (mainly because I know direct
cast is faster) and also this call

[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
romObject(object)

I would figure that FromObject is a class and created on the heap. I would
also assume there is more code inside that method that takes longer to
execute. Whereas the unbox (I don't know what that means necessarily) seems
pretty direct. I don't know, just assuming.

I think it would be helpful to see the dissassembly from the FromObject
method to be 100% sure.

HTH,
CJ
 
Tinman,
In addition to the earlier answers William and I gave, the first is more
correct, although I would use the technique I gave in my first response here
instead of DirectCast.

Using Option Strict On, which requires the first, is more "correct", in that
you are stating that project_id is a GUID, start date is a DateTime... You
are not allowing the compiler make that decision for you...

Also using Option Strict On allows you to catch a number of errors at
compile time, instead of run time.

Hope this helps
Jay
 
thanks guys....

I believe the Get*Type* works better than the DirectCast approach. The
resulting
IL appears "leaner"...

In the initial IL with DirectCast, I was afraid that all the unboxing would
cause a performance
concern since it was going to continue reading data in a loop (While .Read)
........

Cheers...
 
Alright, maybe this is a dumb question, but what is unboxing?


tinman said:
thanks guys....

I believe the Get*Type* works better than the DirectCast approach. The
resulting
IL appears "leaner"...

In the initial IL with DirectCast, I was afraid that all the unboxing would
cause a performance
concern since it was going to continue reading data in a loop (While ..Read)
.......

Cheers...


tinman said:
Hi...

I have the following two excerpts from a method. It basically reads data
from a DataReader and
loads it in a collection.


Excerpt A:
********
With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"), DateTime), _
DirectCast(.Item("end_date"), DateTime), _
DirectCast(.Item("priority"), Integer), _
DirectCast(.Item("description"), String), _
DirectCast(.Item("project_manager"), String)
End While
End With




Excerpt B:
********
With ProjectData
While .Read
Me.Add(.Item("project_id"),
.Item("start_date"),
.Item("end_date"),
.Item("priority"),
.Item("description"),
.Item("project_manager")
End While
End With



Question:

Does automatic casting outperform explicit casting ? When I run ILDASM, I
find
that at each DirectCast, there is unboxing but in Excerpt B, there isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
romObject(object)

Any pointers to articles that explain what goes on "under the hood" with
regards to
casting would be much appreciated as well.

Cheers !
 
CJ,
When you assign a value type to an Object variable that type is boxed. Which
copies the value of the value type to an object on the heap.

When you then assign this Object variable back to the value type variable,
the object is unboxed.

Dim i As Integer
i = 100
Dim o As Object
o = i ' this causes the 100 to be boxed.

i = o ' this causes the boxed 100 to be unboxed

Of course if you have Option Strict On, you need DirectCast

i = DirectCast(o, Integer)

Hope this helps
Jay

CJ Taylor said:
Alright, maybe this is a dumb question, but what is unboxing?


tinman said:
thanks guys....

I believe the Get*Type* works better than the DirectCast approach. The
resulting
IL appears "leaner"...

In the initial IL with DirectCast, I was afraid that all the unboxing would
cause a performance
concern since it was going to continue reading data in a loop (While .Read)
.......

Cheers...
ILDASM,
I
find
that at each DirectCast, there is unboxing but in Excerpt B, there isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
 
Helps tremendously. Thanks for the info on that one Jay.

I think the best way to see it "visually" would be when your watching a
variable (in the watch window) of a base type (i.e. DataRow) thats actually
inherited (i.e MyDataRow of a dataset)

Where it shows your +- graphic and says its a datarow, then there is a sub
type underneath it that tells the actual class type that it is.

I hope that made sense. But again I appreciate your explanation.

So is unboxing an expensive process? given its only a single line of IL but
was curious if it was or not.




Jay B. Harlow said:
CJ,
When you assign a value type to an Object variable that type is boxed. Which
copies the value of the value type to an object on the heap.

When you then assign this Object variable back to the value type variable,
the object is unboxed.

Dim i As Integer
i = 100
Dim o As Object
o = i ' this causes the 100 to be boxed.

i = o ' this causes the boxed 100 to be unboxed

Of course if you have Option Strict On, you need DirectCast

i = DirectCast(o, Integer)

Hope this helps
Jay

CJ Taylor said:
Alright, maybe this is a dumb question, but what is unboxing?
DateTime),
_
DirectCast(.Item("end_date"), DateTime), _
DirectCast(.Item("priority"), Integer), _
DirectCast(.Item("description"), String), _
DirectCast(.Item("project_manager"), String)
End While
End With




Excerpt B:
********
With ProjectData
While .Read
Me.Add(.Item("project_id"),
.Item("start_date"),
.Item("end_date"),
.Item("priority"),
.Item("description"),
.Item("project_manager")
End While
End With



Question:

Does automatic casting outperform explicit casting ? When I run
ILDASM,
I
find
that at each DirectCast, there is unboxing but in Excerpt B, there isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
 
CJ,
So is unboxing an expensive process? given its only a single line of IL but
was curious if it was or not.
Its expensive in that the value needs to be copied from the heap to the
variable.

Its also expensive in that the boxing itself created an object on the heap,
this object will later need to be Garbage collected.

Hope this helps
Jay

CJ Taylor said:
Helps tremendously. Thanks for the info on that one Jay.

I think the best way to see it "visually" would be when your watching a
variable (in the watch window) of a base type (i.e. DataRow) thats actually
inherited (i.e MyDataRow of a dataset)

Where it shows your +- graphic and says its a datarow, then there is a sub
type underneath it that tells the actual class type that it is.

I hope that made sense. But again I appreciate your explanation.

So is unboxing an expensive process? given its only a single line of IL but
was curious if it was or not.




Jay B. Harlow said:
CJ,
When you assign a value type to an Object variable that type is boxed. Which
copies the value of the value type to an object on the heap.

When you then assign this Object variable back to the value type variable,
the object is unboxed.

Dim i As Integer
i = 100
Dim o As Object
o = i ' this causes the 100 to be boxed.

i = o ' this causes the boxed 100 to be unboxed

Of course if you have Option Strict On, you need DirectCast

i = DirectCast(o, Integer)

Hope this helps
Jay

reads
data DateTime), DateTime),
_
String),
_
DirectCast(.Item("project_manager"),
String)
End While
End With




Excerpt B:
********
With ProjectData
While .Read
Me.Add(.Item("project_id"),
.Item("start_date"),
.Item("end_date"),
.Item("priority"),
.Item("description"),
.Item("project_manager")
End While
End With



Question:

Does automatic casting outperform explicit casting ? When I run ILDASM,
I
find
that at each DirectCast, there is unboxing but in Excerpt B, there isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
hood"
with
 
Ok, last question I swear.

Alright, so unboxing takes a variable (more than likely on the heap in most
cases) and creates a copy of that on the heap again on the unboxing process.
And then has to be gc'd as well as the original value (if that original
value exists on the heap as well).

Hmmm...

Option Strict. =)

Thanks Jay!

-CJ

Jay B. Harlow said:
CJ,
So is unboxing an expensive process? given its only a single line of IL but
was curious if it was or not.
Its expensive in that the value needs to be copied from the heap to the
variable.

Its also expensive in that the boxing itself created an object on the heap,
this object will later need to be Garbage collected.

Hope this helps
Jay

CJ Taylor said:
Helps tremendously. Thanks for the info on that one Jay.

I think the best way to see it "visually" would be when your watching a
variable (in the watch window) of a base type (i.e. DataRow) thats actually
inherited (i.e MyDataRow of a dataset)

Where it shows your +- graphic and says its a datarow, then there is a sub
type underneath it that tells the actual class type that it is.

I hope that made sense. But again I appreciate your explanation.

So is unboxing an expensive process? given its only a single line of IL but
was curious if it was or not.




CJ,
When you assign a value type to an Object variable that type is boxed. Which
copies the value of the value type to an object on the heap.

When you then assign this Object variable back to the value type variable,
the object is unboxed.

Dim i As Integer
i = 100
Dim o As Object
o = i ' this causes the 100 to be boxed.

i = o ' this causes the boxed 100 to be unboxed

Of course if you have Option Strict On, you need DirectCast

i = DirectCast(o, Integer)

Hope this helps
Jay

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
Alright, maybe this is a dumb question, but what is unboxing?


thanks guys....

I believe the Get*Type* works better than the DirectCast approach. The
resulting
IL appears "leaner"...

In the initial IL with DirectCast, I was afraid that all the unboxing
would
cause a performance
concern since it was going to continue reading data in a loop (While
.Read)
.......

Cheers...


Hi...

I have the following two excerpts from a method. It basically reads
data
from a DataReader and
loads it in a collection.


Excerpt A:
********
With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"), DateTime),
_
DirectCast(.Item("end_date"),
DateTime),
_
DirectCast(.Item("priority"),
Integer),
_
DirectCast(.Item("description"),
String),
_
DirectCast(.Item("project_manager"),
String)
End While
End With




Excerpt B:
********
With ProjectData
While .Read
Me.Add(.Item("project_id"),
.Item("start_date"),
.Item("end_date"),
.Item("priority"),
.Item("description"),
.Item("project_manager")
End While
End With



Question:

Does automatic casting outperform explicit casting ? When I run
ILDASM,
I
find
that at each DirectCast, there is unboxing but in Excerpt B, there
isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
 
CJ,
Alright, so unboxing takes a variable (more than likely on the heap in most
cases)
By definition a boxed value is on the heap.
cases) and creates a copy of that on the heap again on the unboxing
process.
No, not quite. Unboxing creates a copy of that value on the stack.
And then has to be gc'd as well as the original value (if that original
value exists on the heap as well).
Correct the object that was created when the original value was boxed will
need to GC'd...



If you following the above, remember that a regular reference type (a Class)
can contain value types also, these values can also be boxed & unboxed,
however explaining it is a little more confusing ;-)

Option Strict has no real effect on Boxing & Unboxing.

Hope this helps
Jay

CJ Taylor said:
Ok, last question I swear.

Alright, so unboxing takes a variable (more than likely on the heap in most
cases) and creates a copy of that on the heap again on the unboxing process.
And then has to be gc'd as well as the original value (if that original
value exists on the heap as well).

Hmmm...

Option Strict. =)

Thanks Jay!

-CJ

Jay B. Harlow said:
CJ,
So is unboxing an expensive process? given its only a single line of
IL
but
was curious if it was or not.
Its expensive in that the value needs to be copied from the heap to the
variable.

Its also expensive in that the boxing itself created an object on the heap,
this object will later need to be Garbage collected.

Hope this helps
Jay

CJ Taylor said:
Helps tremendously. Thanks for the info on that one Jay.

I think the best way to see it "visually" would be when your watching a
variable (in the watch window) of a base type (i.e. DataRow) thats actually
inherited (i.e MyDataRow of a dataset)

Where it shows your +- graphic and says its a datarow, then there is a sub
type underneath it that tells the actual class type that it is.

I hope that made sense. But again I appreciate your explanation.

So is unboxing an expensive process? given its only a single line of
IL
but
was curious if it was or not.




CJ,
When you assign a value type to an Object variable that type is boxed.
Which
copies the value of the value type to an object on the heap.

When you then assign this Object variable back to the value type variable,
the object is unboxed.

Dim i As Integer
i = 100
Dim o As Object
o = i ' this causes the 100 to be boxed.

i = o ' this causes the boxed 100 to be unboxed

Of course if you have Option Strict On, you need DirectCast

i = DirectCast(o, Integer)

Hope this helps
Jay

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
Alright, maybe this is a dumb question, but what is unboxing?


thanks guys....

I believe the Get*Type* works better than the DirectCast
approach.
The
resulting
IL appears "leaner"...

In the initial IL with DirectCast, I was afraid that all the unboxing
would
cause a performance
concern since it was going to continue reading data in a loop (While
.Read)
.......

Cheers...


Hi...

I have the following two excerpts from a method. It basically reads
data
from a DataReader and
loads it in a collection.


Excerpt A:
********
With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"),
DateTime),
_
DirectCast(.Item("end_date"), DateTime),
_
DirectCast(.Item("priority"),
Integer),
_
DirectCast(.Item("description"),
String),
_
DirectCast(.Item("project_manager"),
String)
End While
End With




Excerpt B:
********
With ProjectData
While .Read
Me.Add(.Item("project_id"),
.Item("start_date"),
.Item("end_date"),
.Item("priority"),
.Item("description"),
.Item("project_manager")
End While
End With



Question:

Does automatic casting outperform explicit casting ? When I run
ILDASM,
I
find
that at each DirectCast, there is unboxing but in Excerpt B, there
isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
 
Jay B. Harlow said:
CJ,
By definition a boxed value is on the heap.

process.
No, not quite. Unboxing creates a copy of that value on the stack.

Ahhh.. ok that makes sense.
Correct the object that was created when the original value was boxed will
need to GC'd...



If you following the above, remember that a regular reference type (a Class)
can contain value types also, these values can also be boxed & unboxed,
however explaining it is a little more confusing ;-)

Yeah I remember that. Thats why I was curiuos about that because I read
that value types that exist within a reference type (class) will be created
on the heap as well. Only direct value types (if that makes sense) will be
created on the stack (like locals and any variables pertinant to the current
scope.)
Option Strict has no real effect on Boxing & Unboxing.

I was making a joke. poorly. =)

Thanks again for your help.
Hope this helps
Jay

CJ Taylor said:
Ok, last question I swear.

Alright, so unboxing takes a variable (more than likely on the heap in most
cases) and creates a copy of that on the heap again on the unboxing process.
And then has to be gc'd as well as the original value (if that original
value exists on the heap as well).

Hmmm...

Option Strict. =)

Thanks Jay!

-CJ
of
IL
but
was curious if it was or not.
Its expensive in that the value needs to be copied from the heap to the
variable.

Its also expensive in that the boxing itself created an object on the heap,
this object will later need to be Garbage collected.

Hope this helps
Jay

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
Helps tremendously. Thanks for the info on that one Jay.

I think the best way to see it "visually" would be when your
watching
of
IL
but
was curious if it was or not.




CJ,
When you assign a value type to an Object variable that type is boxed.
Which
copies the value of the value type to an object on the heap.

When you then assign this Object variable back to the value type
variable,
the object is unboxed.

Dim i As Integer
i = 100
Dim o As Object
o = i ' this causes the 100 to be boxed.

i = o ' this causes the boxed 100 to be unboxed

Of course if you have Option Strict On, you need DirectCast

i = DirectCast(o, Integer)

Hope this helps
Jay

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
Alright, maybe this is a dumb question, but what is unboxing?


thanks guys....

I believe the Get*Type* works better than the DirectCast approach.
The
resulting
IL appears "leaner"...

In the initial IL with DirectCast, I was afraid that all the
unboxing
would
cause a performance
concern since it was going to continue reading data in a loop (While
.Read)
.......

Cheers...


Hi...

I have the following two excerpts from a method. It basically
reads
data
from a DataReader and
loads it in a collection.


Excerpt A:
********
With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"),
DateTime),
_
DirectCast(.Item("end_date"),
DateTime),
_
DirectCast(.Item("priority"), Integer),
_
DirectCast(.Item("description"),
String),
_
DirectCast(.Item("project_manager"),
String)
End While
End With




Excerpt B:
********
With ProjectData
While .Read
Me.Add(.Item("project_id"),
.Item("start_date"),
.Item("end_date"),
.Item("priority"),
.Item("description"),
.Item("project_manager")
End While
End With



Question:

Does automatic casting outperform explicit casting ? When I run
ILDASM,
I
find
that at each DirectCast, there is unboxing but in Excerpt B, there
isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
 
CJ,
Yeah I remember that. Thats why I was curiuos about that because I read
that value types that exist within a reference type (class) will be created
on the heap as well. Only direct value types (if that makes sense) will be
created on the stack (like locals and any variables pertinant to the current
scope.)

Given:

Public Class Class1
Private m_value As Integer
Private m_object As Object
End Class1

The m_value integer is created on the heap as part of Class1, however the
m_value integer is not a boxed value.

However if I assign m_value to m_object, then m_object will contain a boxed
integer.

m_object = m_value

Hope this helps
Jay



CJ Taylor said:
Jay B. Harlow said:
CJ,
By definition a boxed value is on the heap.

process.
No, not quite. Unboxing creates a copy of that value on the stack.

Ahhh.. ok that makes sense.
Correct the object that was created when the original value was boxed will
need to GC'd...



If you following the above, remember that a regular reference type (a Class)
can contain value types also, these values can also be boxed & unboxed,
however explaining it is a little more confusing ;-)

Yeah I remember that. Thats why I was curiuos about that because I read
that value types that exist within a reference type (class) will be created
on the heap as well. Only direct value types (if that makes sense) will be
created on the stack (like locals and any variables pertinant to the current
scope.)

Option Strict has no real effect on Boxing & Unboxing.

I was making a joke. poorly. =)

Thanks again for your help.
Hope this helps
Jay

CJ Taylor said:
Ok, last question I swear.

Alright, so unboxing takes a variable (more than likely on the heap in most
cases) and creates a copy of that on the heap again on the unboxing process.
And then has to be gc'd as well as the original value (if that original
value exists on the heap as well).

Hmmm...

Option Strict. =)

Thanks Jay!

-CJ

CJ,
So is unboxing an expensive process? given its only a single line
of
IL
but
was curious if it was or not.
Its expensive in that the value needs to be copied from the heap to the
variable.

Its also expensive in that the boxing itself created an object on the
heap,
this object will later need to be Garbage collected.

Hope this helps
Jay

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
Helps tremendously. Thanks for the info on that one Jay.

I think the best way to see it "visually" would be when your
watching
a
variable (in the watch window) of a base type (i.e. DataRow) thats
actually
inherited (i.e MyDataRow of a dataset)

Where it shows your +- graphic and says its a datarow, then there
is
a
sub
type underneath it that tells the actual class type that it is.

I hope that made sense. But again I appreciate your explanation.

So is unboxing an expensive process? given its only a single line
of
IL
but
was curious if it was or not.




message
CJ,
When you assign a value type to an Object variable that type is boxed.
Which
copies the value of the value type to an object on the heap.

When you then assign this Object variable back to the value type
variable,
the object is unboxed.

Dim i As Integer
i = 100
Dim o As Object
o = i ' this causes the 100 to be boxed.

i = o ' this causes the boxed 100 to be unboxed

Of course if you have Option Strict On, you need DirectCast

i = DirectCast(o, Integer)

Hope this helps
Jay

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
Alright, maybe this is a dumb question, but what is unboxing?


thanks guys....

I believe the Get*Type* works better than the DirectCast approach.
The
resulting
IL appears "leaner"...

In the initial IL with DirectCast, I was afraid that all the
unboxing
would
cause a performance
concern since it was going to continue reading data in a loop
(While
.Read)
.......

Cheers...


Hi...

I have the following two excerpts from a method. It basically
reads
data
from a DataReader and
loads it in a collection.


Excerpt A:
********
With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"),
DateTime),
_
DirectCast(.Item("end_date"),
DateTime),
_
DirectCast(.Item("priority"),
Integer),
_
DirectCast(.Item("description"),
String),
_
DirectCast(.Item("project_manager"),
String)
End While
End With




Excerpt B:
********
With ProjectData
While .Read
Me.Add(.Item("project_id"),
.Item("start_date"),
.Item("end_date"),
.Item("priority"),
.Item("description"),
.Item("project_manager")
End While
End With



Question:

Does automatic casting outperform explicit casting ? When
I
run
ILDASM,
I
find
that at each DirectCast, there is unboxing but in Excerpt B,
there
isn't
any.

Snippets of the ILDASM for Excerpt A and B below:

ILDASM (Excerpt A)
****************
IL_0098: ldloc.2
IL_0099: ldstr "description"
IL_009e: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_00a3: unbox [mscorlib]System.Int32
IL_00a8: ldobj [mscorlib]System.Int32


ILDASM (Excerpt B)
****************
IL_0092: ldloc.2
IL_0093: ldstr "description"
IL_0098: callvirt instance object
XXX.Projects.XDataReader::get_Item(string)
IL_009d: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
 
Back
Top