views:

852

answers:

5

Hi,

Does anyone know how much memory is taken up when you create a reference type variable?

String s = "123";

How much memory would 's' take up as a reference, not the data pointing to it?

+4  A: 

Depending on whether you're on a 32- or 64-bit machine, it'll be either a 32- or 64-bit pointer.

mquander
No. Why? How would you refer to an object in memory in a less wasteful way?
mquander
Anthony he is right. on a 32 bit machine, you have the pointer is 32 bits. and 64 bits on a 64 bit machine. You probably got confused with the conversion from bit to byte.
masfenix
I see your point, I withdraw the comment.
AnthonyWJones
+1  A: 

Typicall 4 bytes for the reference is needed

AnthonyWJones
+10  A: 

The size of the reference itself will depend on your processor architecture - 4 bytes on 32-bit, 8 bytes on 64-bit.

Stu Mackellar
+1, or the perhaps more apt answer: a negligibly important amount of space
sixlettervariables
Have you got any reference to documentation on that?
AnthonyWJones
Not authoritative, but try http://msdn.microsoft.com/en-us/magazine/cc163791.aspx. A .Net reference is internally just a pointer to an object on the managed heap.
Stu Mackellar
ECMA-335 (Common Language Infrastructure): 12.1 Supported data types. They are stored in a native-sized integer equating to a pointer size.
sixlettervariables
Nice one thanks.
AnthonyWJones
note that it is dependent on ALL OF the processor architecture, the operating systems bitness AND whether the executable indicated it supported running in 64bit mode.
ShuggyCoUk
Good point - 32-bit exeutables will still have a 4-byte reference size when run under WOW64.
Stu Mackellar
+1  A: 

If you want to check this in code, call:

IntPtr.Size
David Morton
+6  A: 

This is broken down in the following fashion:

String s = "123";

The variable s: this will consume the native pointer size on the current architecture (which is considered 32bit if the OS is 32bit or the process is executing under WoW64), so 32 bits or 64 bits accordingly. In this case s is on the stack, where you to place the string into an array then that space would be consumed on the heap.

The fact that string is an object: 8 bytes of overhead split 4 bytes for the method table, which doubles as the indication of what actual type an object is plus 4 bytes for some housekeeping bits and the syncblock that allows it to be used as the target of a lock statement.

Strings further contain the following:

  • an int for the length of the string in characters
  • an int for the length of the underlying array holding the characters
  • a character which is the first character in the string (subsequent characters are directly after it) or the null character for an empty string

The string is always terminated by the null character so that it can be used directly with C-Style string apis, characters are UTF-16 so two bytes.

string may consume up to twice the amount of memory required to actually hold the character array needed owning to the way StringBuilder's work

Thus the string itself will consume between 16 + (2*n) + 2 and 16 + (4*n) + 2 bytes on the heap depending on how it was created.

This will be complicated by string interning (where two separate instances end up pointing to the same string since it is immutable)

for more discussion of this take a look at this article

ShuggyCoUk
Now that is a thorough answer.
ScottS