Enum memory allocation

[Guest]

Regarding use of enum's, I am wondering what the cost of memory is when creating the enumeration on the calling side, and then using it on the function/method side. See example below. If I understand correctly, what is actually happening on the calling side is an instance of the enum class FavoriteSport is getting created and sent to the PrintFavorite routine with a default value of type int. Is this correct? Say I have a couple hundred uses of this enumeration at the same time (Citrix server for a Statewide application), would I have a couple hundred or more instances of this enum class in memory

I'm still trying to understand .Net and the true object oriented nature of how it works now, so any information would be greatly appreciated

Thanks

Michael Isaac

public enum FavoriteSpor
Basebal
Socce
end enu

Public Sub PrintFavorite(ByVal intFavorite as FavoriteSport
Select Case intFavorite ..
'if Baseball print "I Love baseball" , et
End Su

'calling pro
PrintFavorite(FavoriteSport.Soccer

 

[Derek Harmon]

Regarding use of enum's, I am wondering what the cost of memory is :
an instance of the enum class FavoriteSport is getting created and sent
to the PrintFavorite routine with a default value of type int. Is this correct?

An Enum is a Structure (extending ValueType), and not a Class. Therefore,
there is no explicit creation on the heap for this memory. Instead, it is a field
within a Class, or it exists temporarily on the stack as a local variable.

The cost is typically 4 bytes. Due to 32-bit word alignment, there's usually
little benefit in assiging a smaller numeric type to the Enum (more Enums,
but they're slower to access.)

Say I have a couple hundred uses of this enumeration at the same time
(Citrix server for a Statewide application), would I have a couple hundred
or more instances of this enum class in memory?

You'll have copies of an integer (or perhaps byte, long, etc.) throughout
memory and on the stack. (Although to highlight the magnitude of this
memory consumption, observe that my PDA can hold up to 16 million
enums; hopefully the server for your app is larger than my PDA.)

: :

public enum FavoriteSport
Baseball
Soccer
end enum

Public Sub PrintFavorite(ByVal intFavorite as FavoriteSport)

4 bytes are pushed onto the stack to contain intFavorite, and the
value of this argument has its value copied to it from the calling Sub.

Select Case intFavorite ...
'if Baseball print "I Love baseball" , etc
End Sub

'calling proc
PrintFavorite(FavoriteSport.Soccer)

As this is passing a constant argument, I believe the 4 bytes are pushed
directly onto the stack of the called Sub. Contrast this to,

Dim sport As FavoriteSport = FavoriteSport.Soccer
PrintFavorite( sport)

Which has a 4-byte copy of the Enum in the calling Sub, and pushes a 4-byte
copy of the Enum to the called Sub. Hence, here memory consumption is
8-bytes.

Also observe that both Enums are stored on the stack automatically, and when
each Sub ends, the stack rolls back and the memory consumed by these Enums
are returned to the system W/O requiring a garbage collection.

Their drawback, if any, is all the copying that takes place. But, it doesn't get
any faster than copying four-bytes at a time (at least on 32-bit machines), so
this is ordinarily insignificant.


Derek Harmon

 

[Michael Isaacs]

Thanks - this was very informative to me. Follow up questions ...

The question that then comes up is how VB knows that this is an enum object
if it is only stored as an integer in memory? Ie. how does it know that it
has methods, functions, etc? My manager is concerned that even if only 4
bytes are being sent in to the function, that the function is still creating
some kind of object that allows for these methods, properties, etc to be
accessed.

Also, is there any Microsoft documentation out there that explains this, or
a good web site that anyone knows about?

Thanks,

Mike

 

[Jay B. Harlow [MVP - Outlook]]

Michael,

The question that then comes up is how VB knows that this is an enum object
if it is only stored as an integer in memory?

You know it is an enum object by virtual you defined it as an Enum type.

Ie. how does it know that it has methods, functions, etc?

The compiler sees that it is of type FavoriteSport and knows that
FavoriteSport and acts accordingly.

My manager is concerned that even if only 4
bytes are being sent in to the function, that the function is still creating
some kind of object that allows for these methods, properties, etc to be
accessed.

Unfortunately this is a common misunderstanding, the compiler knows that an
Integer has certain methods and is able to call the methods directly. It
knows that an FavoriteSport has certain methods & is able to call those
directly. The only time a FavoriteSport would be "creating some kind of
object" Object in the sense that it is on the heap, is when you pass it as
an System.Object, System.Enum, System.ValueType or an Interface parameter.
Most of the time you do not/should not do this.

Also, is there any Microsoft documentation out there that explains this, or
a good web site that anyone knows about?

"The Common Language Infrastructure Annotated Standard" by James S. Miller,
from Addison Wesley. The Common Language Infrastructure Standard itself (non
annotated) is available on your harddisk when you install the SDK, for
VS.NET 2003 its at "\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\Tool Developers Guide\docs". Primarily read up on the
difference of Reference Types & Value Types.

Hope this helps
Jay

 

[Michael Isaacs]

Thanks Jay.

I also did a test using enum objects and checking memory usage to confirm
that enum objects only take the amount of memory of the base type (default
integer = 4 bytes). This satisfied my manager on the subject. Also, good
point about integers and the comparison between integer variables and
enums - both do have methods, etc, but are both stored as 4 bytes when used.

Michael Isaacs