what is the size of reference variable
-
That's actually a very good question and I think its 12 bytes (on a 32 bit system). 4 of those are the pointer or the reference, then there's some internal thing (garbage collection?) and I think there's a synchronisation part too. Of course, that's not taking into account whatever you've got on the heap which actually represents your object. I do know for sure that if you're storing vast collections of simple objects it's better to use
structs rather thanclasses. This saves that overhead.Regards, Rob Philpott.
Rob Philpott wrote:
I think its 12 bytes
:confused: IMO at run-time a reference is just a pointer, no more no less, hence 4 or 8B. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Rob Philpott wrote:
I think its 12 bytes
:confused: IMO at run-time a reference is just a pointer, no more no less, hence 4 or 8B. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Agreed, just 4/8 bytes on the stack. But on the heap you get the extra eight bytes on top of the object itself. I think - not certain. Someone, somewhere did a wonderful job of explaining it all here on CP.
Regards, Rob Philpott.
-
Rob Philpott wrote:
I think its 12 bytes
:confused: IMO at run-time a reference is just a pointer, no more no less, hence 4 or 8B. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Found it - nice article.... .NET Type Internals - From a Microsoft CLR Perspective[^]
Regards, Rob Philpott.
-
Rob Philpott wrote:
I think its 12 bytes
:confused: IMO at run-time a reference is just a pointer, no more no less, hence 4 or 8B. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Then why is it such a pain in the ass to convert references to IntPtr and vice versa (for using with platform invoke). As I understand it - IntPtr is a typical substitute for a general unmanaged pointer (int*, void*, ...), so why can't one use something like
SomeReferenceType instance; PInvokeCall((IntPtr) instance);where PInvokeCall has signaturevoid PInvokeCall(IntPtr param);No trolling, I am really curious about this. -
Found it - nice article.... .NET Type Internals - From a Microsoft CLR Perspective[^]
Regards, Rob Philpott.
Thanks. Too long to read right now. In the mean time I think we understood the question in different ways. "What is the size of a reference variable?" to me means "What is the size of a reference?" (hence 4 or 8B) and not "What is the size of an object?". Which I guess gets dealt with in the article; I hope it also mentions objects get aligned in memory, I think to a 32B boundary. So, assuming that is correct, the smallest object costs 32B of heap space. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Then why is it such a pain in the ass to convert references to IntPtr and vice versa (for using with platform invoke). As I understand it - IntPtr is a typical substitute for a general unmanaged pointer (int*, void*, ...), so why can't one use something like
SomeReferenceType instance; PInvokeCall((IntPtr) instance);where PInvokeCall has signaturevoid PInvokeCall(IntPtr param);No trolling, I am really curious about this.A small object (small enough to be in a regular heap, not the large-object-heap) is a moving target: when the GC runs it can move it around to perform heap compaction. Managed code is fine with this, however your native code would not be aware of this, so the pointer could become invalid, unless the object got pinned first. That is exactly what the ref-to-ptr convertors ("fixed", GCHandle, Marshal) do. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Thanks. Too long to read right now. In the mean time I think we understood the question in different ways. "What is the size of a reference variable?" to me means "What is the size of a reference?" (hence 4 or 8B) and not "What is the size of an object?". Which I guess gets dealt with in the article; I hope it also mentions objects get aligned in memory, I think to a 32B boundary. So, assuming that is correct, the smallest object costs 32B of heap space. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Luc Pattyn wrote:
So, assuming that is correct, the smallest object costs 32B of heap space.
At the risk of really being quite boring, I was playing around with that the other day, trying to work out how much space a boolean takes as a class member variable. Turns out the first one takes 32 bits, the second no bits, the third no bits, the fourth no bits, the fifth 32 again, etc. etc. So, sort of one byte collectively rounded up to the nearest 32 bit word.
Regards, Rob Philpott.
-
This was the question asked me in an interview.
“You will never be a leader unless you first learn to follow and be led.” –Tiorio "Coming together is a beginning, staying together is progress, and working together is success." Henry Ford
OK - that has to be a contender for daftest technical question you're likely to receive in an interview. Unless you're going for a really senior post, I wouldn't expect that you'd carry this round in your head. I certainly wouldn't mark you down for not knowing it.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Luc Pattyn wrote:
So, assuming that is correct, the smallest object costs 32B of heap space.
At the risk of really being quite boring, I was playing around with that the other day, trying to work out how much space a boolean takes as a class member variable. Turns out the first one takes 32 bits, the second no bits, the third no bits, the fourth no bits, the fifth 32 again, etc. etc. So, sort of one byte collectively rounded up to the nearest 32 bit word.
Regards, Rob Philpott.
No surprise here. That is due to padding (inserting unused bytes, or rounding up the address), exactly like what happens when storing bytes in a C/C++/C# structure. By default elements of a struct (and the overall size of a struct) get word-aligned to prevent an access to the next 16-bit or larger quantity to cause a performance hit or an exception. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
No surprise here. That is due to padding (inserting unused bytes, or rounding up the address), exactly like what happens when storing bytes in a C/C++/C# structure. By default elements of a struct (and the overall size of a struct) get word-aligned to prevent an access to the next 16-bit or larger quantity to cause a performance hit or an exception. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Cool. :)
Regards, Rob Philpott.