Click here to Skip to main content
15,867,488 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
What is the performance impact of using an enum set which starts with a value say 1026 (as opposed to 0) and does this have any influence on execution speed or switch block layout in the assembly?

My initial thought is that in a customary instance (first val = 0) this may be used as an offset in the memory block somehow, however starting the enumeration @ 1026 affects this perspective a bit... let alone have enum values with spaces in their assignment eFlag.val0 = 1026, eFlag.val1 = 5678,...?

However it would also make sense that since the enum is always going to be the sizeof the base type, that this could be just used as a form of label in the assembled code, and it really doesn't matter...

..anyone know?
Posted

Every enum value is per default principally just an integer. So it's irrelevant what numbers you assign. You can btw set the base type which may reduce memory impact.
MIDL
public enum Bla : byte
{
    A=123,
    B=255
}
 
Share this answer
 
Comments
ely_bob 3-Jul-10 17:21pm    
.. I guess that makes sense, the approach I was using had me thinking that their value actually meant something. So basically at a certain layer of abstraction the string for the enum, is a key in a dictionary like structure which returns the int ....

and as per your base class recommendation, this was how i was dong it, however i had an issue between my data layer (setting unique ID's ) and my code layer (resetting various enums back to start each at 0)... I ended up just moving up a integer type size from byte to ushort... just so i can more easily import the higher value ones, without gobbling up memory(I'm using these effectively as a pointer table to some very low level code, to be used in a genetic-like library)... and each population member has a very large array of these values so just by going from byte to short is a serious decision.. but ya gotta do what ya gotta do...
ely_bob 3-Jul-10 17:22pm    
Reason for my vote of 5
Very close to the answer I was looking for.
I'm pretty sure, it won't have any noticable performance impact. But it sounds like you might be better off with declaring readonly fields or constants for each of the type sizes.
 
Share this answer
 
Comments
ely_bob 3-Jul-10 17:12pm    
Normally I would agree with you however the current implementation architecture does not allow for that.(and I'm generating the code for these enumerations from a database.. so they would get REALLY ugly.) currently the enumerations are in the hundreds and this is just test data!
ely_bob 3-Jul-10 17:22pm    
Reason for my vote of 5
A very good method...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900