overhead of using unbounded support and @optional fields

4 posts / 0 new
Last post
Offline
Last seen: 1 month 3 weeks ago
Joined: 06/03/2020
Posts: 4
overhead of using unbounded support and @optional fields

Hi all, a few questions about RTI DDS that arised while building my system's data model

1. We are thinking about either seprateing data types into small chunks or using large messages with the @optional key.

I'd like to know what is the overhead of using that key in case i'm not using the specific field.

  • Does the message still transport the data of the null pointer?
  • Does it save any communication resources in case of basic data types?
  • If i don't know which memebers are used is there an elegant way to avoid checking for NULL pointers on the recieving side (C++)?

2. What is the overhead of using unbounded support for strings / sequences in cpp and jave?

3. Unrelated to performance, im trying to understand why https://community.rti.com/rti-doc/510/ndds/doc/html/api_dotnet/structDDS_1_1Time__t.html has seconds described as int32, what does the negative time represent?

Offline
Last seen: 1 week 1 day ago
Joined: 04/02/2013
Posts: 145

Hi,

When an optional member is not set, the data is not sent on the wire.
The enconding of an optional member depends on the Extensibility kind of the type that contains it. To encode an optional member a header field is serialized to indicate the presence of the value. For Mutable types that header already exists, so an optional member doesn’t add extra bytes. For Appendable and Final types the header is extra. For that reason, basic types do not benefit from being optional in terms of communication resources.
Optional members and unbounded sequences require heap allocations, while non-optional members and bounded types can use pre-allocated fixed-size buffer pools.

If you use the Modern C++ API, optional members map to dds::core::optional<T> (similar to std::optional<T>) and you can call has_value() and then the operator*, or you can call value() directly and expect an exception if the value is unset:

if (sample.optional_member().has_value()) value = *sample.optional_member();

// or

value = sample.optional_value().value(); // throws if unset

The second is a signed integer to allow representing some special values such as Time::INVALID. 

 

Offline
Last seen: 1 month 3 weeks ago
Joined: 06/03/2020
Posts: 4

Thank you for the quick response.

Besides the alloction of the unbounded types id like to know what happens in terms of bandwidth over the wire when using a bounded type such as a string or sequence  and using just a part of that constant size in relation to using an unbounded string.

Offline
Last seen: 1 week 1 day ago
Joined: 04/02/2013
Posts: 145

There's no difference. Only the actual size of the string/sequence in a specific sample is serialized and sent on the wire, regardless of wether it's bounded or unbounded.