Compressed Complete Type Objects #4271
jrw972
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
opendds_idl
can generate minimal and complete type objects for IDL-defined types. The type objects are used for discovery and DynamicData features. We are entertaining the idea of only generating complete type objects so that various features (TryConstruct, Query Condition, Content Filter, Observer, MultiTopic, Security, etc.) can use the same API for type information. Before doing so, we wanted to understand how this change would impact code size.opendds_idl
generates maps from TypeIdentifier to TypeObject. One map is for MinimalTypeObjects, and another map is for CompleteTypeObjects. For this experiment,opendds_idl
converted each map to aTypeIdentifierTypeObjectPairSeq
and serialized the sequence to an XCDR buffer. The buffer for CompleteTypeObjects was then compressed using bzip2. The code for the experiment is at https://github.com/jrw972/OpenDDS/tree/compressed-complete-type-objects. Thus, for an IDL file, we have the serialized size of the MinimalTypeIdentifiers + MinimalTypeObects (Minimal Size), the CompleteTypeIdentifiers + CompleteTypeObjects (Complete Size), and a compressed version of the latter (Compressed Size).type_object_compression.csv
Measurements were taken for 28 IDL files in the repository; the results are attached. The first column is the name of the TypeSupport file that was analyzed. The next three columns are Minimal Size, Complete Size, and Compressed Size, respectively. The last three columns represent Complete Size / Minimal Size, Compressed Size / Minimal Size, and Compressed Size / Complete Size, respectively.
The increase in size caused by using Complete instead of Minimal ranged from 1.2 to 1.9, with an average of 1.6. CompleteTypeObjects contain the names of members, while MinimalTypeObjects do not.
The increase between Minimal Size and Compressed Size ranged from 1.9 to 0.33. This scales with Minimal Size. For a very small Minimal Size of 64 bytes, the Compressed Size was 119 bytes. The break-even point appears to be around 667 bytes. That is, if the Minimal Size is 667 bytes, then we can use a Compressed CompleteTypeObject with no change in size. As the Minimal Size gets larger, the effects of compression become more pronounced. For example, a Minimal Size of 10,315 yielded a Compressed Size of 3,408.
The same observations hold for Complete Size versus Compressed Size, although the break-even point is much lower due to the larger size of CompleteTypeObjects. The break-even point, in this case, is around 162 bytes. The increase in size ranges from 1.2 to .23. Again, the effects of compression are more pronounced as the type information grows larger.
Given a break-even point of 667 bytes, it seems like using Compressed CompleteTypeObjects is feasible.
Beta Was this translation helpful? Give feedback.
All reactions