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

 enum smaller : byte { one, two, three };

2

7 Answers

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

14

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.

5

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.

3

If you are mapping the model with enum to another model, or serializing it, or your enum is reflected to the database column – then I would suggest you to specify the type explicitly.

---

Scenario: You have a column in database: status_id with type tinyint. And you have enum in your code: enum Status { Well = 1, Bad = 2 }. And you use this enum in some entity. Let's say you use entity frameworks core 2.0. If you try to read/write this entity from database you will get the error "Unable to cast object", unless you specify the byte type explicitly.

1

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.

1

You should not assign a certain integer type to enumerations and let C# fall back to the default int¹ 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.

¹ By default, the associated constant values of enum members are of type int

1

In .Net core, if you call Enum.IsDefined to check if the passing in value existed in an enum, you should ensure types are the same.

ArgumentException: Enum underlying type and the object must be same type or object must be a String.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy