[ros-users] [Discourse.ros.org] [Next Generation ROS] Maximum amount of publisher / subscriptions per node

William Woodall ros.discourse at gmail.com
Thu Mar 2 03:10:41 UTC 2017

[quote="firesurfer, post:1, topic:1391"]
I was wondering if it's bad in terms of resources to have a great amount of publishers and subscriptions to the same topic in a single application / node or does ROS2/DDS manage them in the background ? Would it be better to have some kind of TopicManager that returns / manages instances of publishers/subscription inside an application. (And all classes that want to use a publisher ask the TopicManager for an instance of this publisher)

I would say that is bad to have many instances of publishers or subscriptions on the same topic in the same node, if you can avoid it and you don't mind them sharing queues.

In ROS 1, at least publishers, and I think subscribers, for topics were singletons. I know that if you created a publisher on topic foo in one place, and in another part of the code you created a publisher on the same topic foo then you'd get a handle to the same publisher. This is bad, for example, when you wanted to specify a different queue size for each, see:


But is was good, on the other hand, for avoiding duplication of resources when you didn't mean to do so.

If it the same is true for subscribers in ROS 1 (I didn't check yet), then it could also be bad that they would share the same queue. Consider a subscriber with a queue size of 10 and the user creates two subscribers, each with a different callback but on the same topic. When a new message is received on the topic, does the message get delivered to both callbacks or just one? If it is delivered to both, what happens when one callback is really slow, does it keep the messages in the queue until all callbacks are done with each message?

In ROS 2 we wanted to make sure that each instance of a publisher or a subscription had the option to have their own queue. That makes the semantics clearer and it makes it possible to write code that cannot be interfered with from other code in the same process (which can be a concern when using the ROS API's from within a library or when making nodelets). The trade-off is that each time a user creates a publisher in ROS 2, there will a queue and any other associated overhead generated as well.

That all being said, I think that we make users aware of this, then making a singleton for your publishers and subscriptions is something the user can do on their own.

[quote="firesurfer, post:1, topic:1391"]
Also do I have to worry about a large amount of different topics in the system? Is the amount of topics somehow related to a increase in cpu / memory usage or do I just pay cpu/memory if I'm sending/recieving messages on a topic?

I don't think you need to worry about it too much. I'm not 100% certain about the overhead on the network, but you could expect some overhead in memory/cpu usage and possibly some overhead on network due to introspection and discovery processes. However, it would always be better to only create new publisher and subscription instances when you explicitly need a unique one with it's own settings and resources.

[Visit Topic](https://discourse.ros.org/t/maximum-amount-of-publisher-subscriptions-per-node/1391/2) or reply to this email to respond.

More information about the ros-users mailing list