tags:

views:

813

answers:

5

If you have an enum in your application and you only have a few items, should you for the underlying type to be the smallest possible type?

    enum smaller : byte
    {
        one,
        two,
        three
    };
+14  A: 

No. Don't prematurely optimize unless you've proved with a profiler that it's actually a problem.

JaredPar
I think .NET is optimised for Enums to be ints anyway.
Ray
To be clear, I was talking about best practices rather than optimization, though this question came across as an optimization question.My point was really since you can specifiy it, should you "always" specify or should you or let the compiler decide?I guess leave as is works for both.
ghost
how would you prove with a profiler whether byte or int is more efficient?
Brian R. Bondy
@Brian, many different ways. The one that comes to mind is memory stats. If you notice a particular object is created in enough bulk that it's size is noticeable on a profiler then you can start looking at ways of shaving down the size of the structure. This would be one possibility.
JaredPar
I don't think you'd notice with enums for typical use, but I guess that's your point :)
Brian R. Bondy
@Brian exactly :). I'm not saying this optimization is not without it's uses. We have done this type of optimization before on our code base (usually C++ bitflags). But we had a lot of profile data to back this up when we did it.
JaredPar
If you prove with a profiler that something is the problem, it wouldn't be premature optimization.
strager
If you want to shave to 5 bits off per enum, I'd say switch to another language/framework. I'd be more worried about strong references than that
Chris S
A: 

What would be gained? You'd save a whopping 3 bytes of memory, at the cost of slightly slower execution and less intuitive or readable code. (Reading this, I have to wonder whether pyou actually had a reason for making it a byte, and what that reason might have been. Presumably you went out of your way to use a non-default type for a reason).

If you plan to store millions of these things then yes, saving a few bytes on each may pay off. Otherwise, no.

It's the same reason you don't typically use byte or short instead of int.

jalf
A: 

You should not assign a certain integer type to enumerations but let the .NET environment figure out the best "size" for the enum. As JaredPar said, if you change the data type, you should definitely check whether it actually helps.

The thing is that 32-bit integers are "natural" on x86 processors because they can be easily align in an optimal fashion.

SealedSun
+5  A: 

Relating to best practice:

When you don't have a particular reason for making the enum a type byte, you should leave it as the default.

Any time you use an enum in a switch statement you should have a "default" clause for an invalid enum value. So it doesn't matter if you are checking for 256-NumRealEnumValues or 2^32-NumRealEnumValues. Both will have a default clause that handles all invalid cases.

One reason for explicitly setting the type of the enum, is if you want your enum to correspond to another type in your program and you need to explicitly cast between them.

Changing the type to the smallest fit will not help you with versioning problems either. Unless you have exactly the max size of the enum filled out. By versioning problems I mean when you have a compiled dll using the enum, then you add a new enum value, some code may execute that was not meant to go in the "default" clause of a switch statement.

Relating to efficiency:

No there is no benefit in terms of efficiency to make it a byte.

int is more efficient to use because the cpu on x86 has 32-bit registers. Copying into a register is done 32-bits at a time.

When you use a smaller type, you have to zero out part of the register and copy into the rest of the register's lower order bits.

Brian R. Bondy
+1  A: 

The only reason to do this is if you are storing or transmitting this value using a defined protocol that demands the field to be of that size.

Juliano
I wouldn't say that's the only reason. I often do this because I need to keep a hundred million or more items in memory, and the three bytes per record savings is quite significant.
Jim Mischel
@Jim: If you have so many items in memory, it is more likely that you have a problem somewhere else. You are sacrificing performance for space. You should either swap those items from memory, or get more memory.
Juliano