smallest type

  • Thread starter Thread starter Bob
  • Start date Start date
B

Bob

Hi,
I have a newbie question. What is the smallest type object size? I am
doing some calculation with individual bits and want to minimize memory
usage. I though bool might do it but it seems like each bool is a
byte, instead of a bit. Is bool the smallest possible type?

Thanks,
Bob
 
Bob said:
I have a newbie question. What is the smallest type object size? I am
doing some calculation with individual bits and want to minimize memory
usage. I though bool might do it but it seems like each bool is a
byte, instead of a bit. Is bool the smallest possible type?
Click to expand...

If speed is important use byte else you can try the
System.Collections.BitArray class.

Arne
 
Thanks for all the quick replies. By use byte, do you mean that an
byte[] where all the entries are either 0 or 1 will perform faster than
a similarly size bool[]?

Thanks,
Bob
 
By use byte, do you mean that an
byte[] where all the entries are either 0 or 1 will perform faster than
a similarly size bool[]?
Click to expand...

I think they will perform pretty much the same, since bytes and bools
are usually treated the same way by the runtime. Both types are 1
byte.


Mattias
 
Bob said:
Hi,
I have a newbie question. What is the smallest type object size? I am
doing some calculation with individual bits and want to minimize memory
usage. I though bool might do it but it seems like each bool is a
byte, instead of a bit. Is bool the smallest possible type?

Thanks,
Bob
Click to expand...


It depends on what you mean with "object" size, the smallest *Reference type* size type is
an int.
byte b = 1;
object o = b;
here, o will take 12 bytes (on X86), 8 bytes object header plus 4 bytes for the byte value.

If you mean primitive type size, then by definition the smallest type is a byte, but again
it highly depends on where and how they are allocated.

void Foo()
{
byte b;
int i;
...

In above sample, both b and i will be stored on the stack, both i and b will occupy a slot
on the stack( Int32 on x86).
void Foo()
{
byte b;
int i;
byte b2;
byte b3,
byte b4;

In above, the four bytes will occupy a single slot (4 bytes on X86) just like i. so here the
same amount of memory is used as the previous sample.

class Foo{
byte b;
int i;
byte b2;
byte b3,
byte b4;
}

class Bar {
byte b;
int i;
}

Same here, An instance of Foo or Bar will occupy the same amount of memory, that is, 8
bytes header plus 8 bytes for the data members.
Conclusion, it makes little sense to use a smaller value than an int if you can't combine a
number of these small integer values.

Willy.
 
Mattias Sjögren said:
I think they will perform pretty much the same, since bytes and bools
are usually treated the same way by the runtime. Both types are 1
byte.
Click to expand...

mmm... I know that in .net a bool is a 4 bytes, and used as a Int32 in
compiled IL for compares.
And for performances a 4 bytes on a 32bits architecture is best over each
other lengths.
If the aim is a small flags data type use an enum x : byte

Personally I will avoid these thoughts about memory allocation in .Net, sice
it is fully managed by the famework and the garbage collector (also the data
in the taskmanager about .net apps are all lies).
 
Mattias Sjögren said:
You do eh? And yet Console.WriteLine(sizeof(bool)) prints 1.
Click to expand...

And my IL says that bool x = true is

L_0001: ldc.i4.1

i4 stays for Int32.
1 stays for the "true" value (0 is false).

And now? ;)
 
Fabio said:
And my IL says that bool x = true is

L_0001: ldc.i4.1

i4 stays for Int32.
1 stays for the "true" value (0 is false).

And now? ;)
Click to expand...

Now ..... the ldc is not relevant, ldc does nothing else that storing the value 1 on the
execution stack (not to be confused with the real thread stack), what's important here is
the store instruction probably a stloc.0, where location 0 is a local variable declared as
bool.
Rest assured, a bool takes one byte in memory, but as I said in another reply all depends on
the context.

Willy.
 
Now ..... the ldc is not relevant, ldc does nothing else that storing the
value 1 on the execution stack (not to be confused with the real thread
stack), what's important here is the store instruction probably a stloc.0,
where location 0 is a local variable declared as bool.
Click to expand...

But there is some documentation about this?
I don't understand: why use a i4 instruction if it is only one byte?
IL would cause itsefl an umbalanced stack :)
Rest assured, a bool takes one byte in memory, but as I said in another
reply all depends on the context.
Click to expand...

Yes, you're right.
 
Bob said:
Thanks for all the quick replies. By use byte, do you mean that an
byte[] where all the entries are either 0 or 1 will perform faster than
a similarly size bool[]?
Click to expand...

BitArray should work with individual bits in a backing array, which
means it should be 8 times more efficient (in terms of space) than
bool[].

byte[] containing only 0 and 1 should perform about the same as bool[].

-- Barry
 
Fabio said:
And my IL says that bool x = true is

L_0001: ldc.i4.1

i4 stays for Int32.
1 stays for the "true" value (0 is false).

And now? ;)
Click to expand...

The CLI *stack* doesn't model bytes. It has only 6 types:

* 32-bit integer
* 64-bit integer
* native integer
* object
* floating-point number
* pointer type, without distinction as to what's being pointed to

The actual IL instructions permit more data types to be implemented in
terms of these primitives.

See ECMA 335 Partition III Section 1.1 for more details.

-- Barry
 
Back
Top