Boxing and Unboxing of Value-Types when passed to a method call

  • Thread starter Thread starter ALI-R
  • Start date Start date
Bruce Wood said:
A little confusion here, where you say that "if they are declared 'ref'
they don't get their own slot."

Yes they do. It is just that the slot is for a reference, which is a
special type of value that points to another value. All the "ref"
keyword on an int argument does is tell the method, "this value is an
address that points to a value of type int that is stored elsewhere."
It also tells the caller that rather than copying the int value from
one stack location (where it is stored) to another (where the method
argument is stored), it should place a reference to the int value on
the stack as the method argument.

Every method argument* gets a "slot" on the stack, although the "slots"
may vary in size depending upon the type of the argument. Arguments to
parameters marked "ref" are merely slots for references, rather than
slots for values.
Click to expand...

I think I'll need to think about this further and work out exactly how
to phrase it. My article needs changing, I think.
*If you use the "params" keyword then you may have arguments that do
not have individual slots on the stack. The "params" keyword really
does fundamentally change the way that arguments are passed into a
method.
Click to expand...

Yup.
 
I can produce other incorrect quotes from MSDN if you want. It's not
perfect. &
But you gave the misleading impression that value types only ever
"live" on the stack. That's simply not true.
Click to expand...

Thanks for the info, I never knew that.

Ab.
 
Aboubakr,
Thanks for your help and monitoring this thread.
I think Jon Skeet is right.I was reading another article the other day
about Differences between DataReader and Dataset in which I found a stupid
mistake by MSDN about how Datareader retrieves
Rows from Database(Which is very obvious to everybody).They could make a
mistake like anyone else.

Cheers,
Reza Alirezaei
Abubakar said:
I can produce other incorrect quotes from MSDN if you want. It's not
perfect. &
But you gave the misleading impression that value types only ever
"live" on the stack. That's simply not true.
Click to expand...

Thanks for the info, I never knew that.

Ab.

Jon Skeet said:
I can produce other incorrect quotes from MSDN if you want. It's not
perfect.
"incorrect"!

It is - structs are created on the stack *and* on the heap.
Click to expand...
(probably
in
Click to expand...
and
Click to expand...
 
Ali,

Why you bother for boxing and unboxing on Net. The used OS needs processors
with speeds which are almost all above the 0.5 Ghz. Boxing and unboxing is
in that kind of computers nothing.

Boxing and unboxing can be in my opinon only still be important on the
CE-Network.

When there is a datareader involved as you write or any other IO like that,
than the reading will take that much time, that you can forget in my opinion
the time for boxing and unboxing, there are better places to win processing
speed.

Just my opinion.

Cor
 
Cor Ligthert said:
Why you bother for boxing and unboxing on Net. The used OS needs processors
with speeds which are almost all above the 0.5 Ghz. Boxing and unboxing is
in that kind of computers nothing.

Boxing and unboxing can be in my opinon only still be important on the
CE-Network.

When there is a datareader involved as you write or any other IO like that,
than the reading will take that much time, that you can forget in my opinion
the time for boxing and unboxing, there are better places to win processing
speed.
Click to expand...

Boxing has performance penalties in many ways:

1) It involves creating an object on the heap, often for no reason
other than boxing. This has clear garbage collection and memory usage
implications. Consider an ArrayList with a million byte entries and
imagine the usage there compared with a byte array, for example.
Fortunately, generics will solve this problem with List<byte> etc.

2) While an individual box or unbox operation is cheap, it can all
mount up when it's done an awful lot. For instance, sorting a large
list of boxed values could easily involve a lot of unboxing, and after
a while it really *does* make a significant difference.

It's not worth worrying about for individual operations, and as you say
when there's IO involved that's likely to dwarf it, but it can still
easily be important on desktops.
 
Cor,

I'm going to deal with more complex data strcutures down the road and as Jon
Skeet said ,it might not be important in one indivitual operation but when
it comes to complex processing it dose.
By the way I was just curious to know how C# handles these issue.Anyways
your tip is also very important and I appreciate it.

Cheers,
 
I think Jon Skeet is right.I was reading another article the other day
about Differences between DataReader and Dataset in which I found a stupid
mistake by MSDN about how Datareader retrieves
Rows from Database(Which is very obvious to everybody).They could make a
mistake like anyone else.
Click to expand...

I hope we all make sure that the mistakes in the documents get reported to
microsoft by using the "send comments on this topic" link at the end of
msdn pages.

Ab.


ALI-R said:
Aboubakr,
Thanks for your help and monitoring this thread.
I think Jon Skeet is right.I was reading another article the other day
about Differences between DataReader and Dataset in which I found a stupid
mistake by MSDN about how Datareader retrieves
Rows from Database(Which is very obvious to everybody).They could make a
mistake like anyone else.

Cheers,
Reza Alirezaei
Click to expand...
 
I hope we all make sure that the mistakes in the documents get reported to
microsoft by using the "send comments on this topic" link at the end of
msdn pages.

Ab.
Click to expand...


I Always do.

ALI
 
Back
Top