Size and overhead of enumerations

3 posts / 0 new
Last post
Last seen: 4 months 4 weeks ago
Joined: 08/17/2023
Posts: 1
Size and overhead of enumerations

Historically we have been passing enumerations as longs. We just switched over from another DDS library, and we want to start passing enums.

However, we are concerned about the bandwidth. How many bytes is an enumeration? Is there any overhead associated with an enum that would make it more cumbersome than a simple long?


Howard's picture
Last seen: 2 days 20 hours ago
Joined: 11/29/2012
Posts: 580

Enums are sent in 4 bytes as integers when they are members of user data structures.

However, the definition of an enum is a part of the type object that describes a data structure and that is sent with the type object of every data structure that uses the enum at discovery time...just sent once between each pair of participants. 

So, the size of an enum (#members, string length of the identifier for each enumerated value) will contribute to the size of the type object....and I have certainly seen enums that have 10s if not 100s of values, with each value identifier being 20-60 bytes long...can make the type object bigger than if the enum wasn't used.

But how that may impact the discovery timing in your system will will only happen when applications are started, but not after discovery is complete.  And generally, will not make any significant impact.

Last seen: 9 hours 14 min ago
Joined: 06/17/2019
Posts: 47

Enums are 4 bytes (the same as long). You can confirm this with our debugging and analysis admin console, by going to the "DDS Data type" tab.
Here is an example view in admin console using shapesdemo and the ShapeType.idl which is located in your <install_dir>\rti_connext_dds-7.2.0\resource\idl\ShapeType.idl

You can confirm this in wireshark using our sample dissector. You will have to turn off shared memory if the reader and writer are on the same machine so it will be forced to use the loopback interface. And you need to start the wireshark capture prior to creating the reader and writer so the dissector has the relevant discovery context. 

One consideration with enums, is the ascii member and value names are shared during discovery (assuming you have typecode or typeobject enabled).

However if you're not sharing datatype information during discovery this isn't a concern. And if you're using Connext 6+ then by default the typeobject information is compressed so this is slightly less of a concern. 
You can determine how many bytes an enum contributes to the _uncompressed_ typeobject in admin console under the rightmost column above, Or by selecting it in wireshark if you have typeobject compression disabled. 
But you likely have typeobject compression enabled. If this is the case you can see how large the entire compressed typeobject is in wireshark by selecting the PID_TYPE_OBJECT_LB within the data(w) or data(r) packet. 

Another advantage of enums is invalid values can be filtered out. And you can specify defaults using the @default_literal annotation