We are in the planning stage of an embedded application which we would like to build using plugin modules in a publish/subscribe environment. We've been looking at DDS Micro as a possible middleware for this.
A current concern is the memory usage per publisher/subscriber. From the numbers in this thread, it looks like at least 5K of RAM is consumed per subscriber/publisher per topic. Is this correct? If so, is there any way of cutting this down? For the current application, we will only need to transport messages within one machine - no need for network communication or remote discovery. Could this be used to cut the footprint down?
Thanks,
Jack
Hi Jack,
The memory usage per data-reader/data-writer is around 5KB plus any additional resources based on how many instances to keep track, reliability etc. We are currently working on Micro 2.4.6 were there are many improvements in overall memory usage. However, the base numbers are not expected to be much lower for the data-reader and data-writers.
However, you mention that there will be no off-board communication. Does it mean that all the data-readers and data-writers will exist within the same domain-participant, or will you have multiple domain-participants? Micro can omit the the use of RTPS when sending from data-writer to a data-reader within the same domain-participant. Removing RTPS could save maybe 2-3 KB per data-reader and data-writer.
What is an acceptable memory usage for a data-reader or data-writer in your case?
If you need to send from a data-writer to a data-reader within the same machine, but within different domain-participants, it is possible to develop a custom Micro transport that may be able to use a more efficient I/O layer.
To give a better answer I would need to have a better understanding of the overall architecture and the intended use of DDS since for example DDS discovery also consumes memory. If you do not want to give details in a public forum please send an email to support@rti.com. With a few more details I can give a much better answer.
regards,
Tron