Is object NodeHandle::serviceClient<theService> small?

Question

Dear all,

I'd like to call a service in my main loop. This led me using

NodeHandle::serviceClient<theService>

At the moment I create a new NodeHandle::serviceClient for each service call (ie at each step ~ very often), is that correct practise?

My question relates to how big object NodeHandle::serviceClient is really, because if this is small it is fine to instantiate on the stack at each loop. This question assumes objects theService are small as well.

--- EDIT ---

Although I have an alternative (simply not creating the object at each loop: easy!), I am still interested in knowing whether the class is heavy or not... From reading the source I would say it only contains 3 pointers (so not a big deal to instantiate it in a loop) but maybe there are subtleties I do not understand... Anyone knows about it?

Thanks,

Antoine.

---

Originally posted by arennuit on ROS Answers with karma: 955 on 2014-10-15

Post score: 0

---

Original comments

Comment by Adolfo Rodriguez T on 2014-10-16:
What does 'heavy' mean, and what would be the negative consequences of a 'heavy' object on your application?.

On your source reference: The implementation follows the opaque pointer (PIMPL) idiom. The pointed-to instance containing the implementation details is allocated on the heap.

Comment by arennuit on 2014-10-16:
I admit deciding what is heavy and what is not is up to the specific app. Having a PIMPL (which I had not noticed) makes it heavier though. Things are now clear to me. Thanks for your help!

Comment by Adolfo Rodriguez T on 2014-10-16:
So what action do you take when you have a 'heavy' object?. I'm just curiously wondering what kind of problems you're running into, or trying to avoid.

Comment by arennuit on 2014-10-16:
I have a vector of services to call in an order changing over time, and I was wondering whether to sort the vector directly or to switch to something like an STL view or maybe a list (I initially wanted to avoid these last two).

Comment by Adolfo Rodriguez T on 2014-10-17:
Ack. I'd still benchmark the naive implementation just to make sure no premature optimization is taking place.

Comment by arennuit on 2014-10-17:
After this discussion it really appears too risky to move the service objects around (because of potential things happening under the hood, in the PIMPL or in premature optim as you mentioned), so I'll keep it safe and go for a clean STL view or something close... Thanks a lot!

Answer 1

You can still create the service client outside your loop as an automatic variable (ie. on the stack), and prevent the constant and unnecessary creation/destruction of multiple clients within the loop.

The template parameter is used to determine the type of messages to be used by the client, that is, the request and response types. Its type should not influence whether you create client instances on the stack or heap, or inside/outside a loop.

---

Originally posted by Adolfo Rodriguez T with karma: 3907 on 2014-10-15

This answer was ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by arennuit on 2014-10-15:
Hello Adolfo, sure this is the preferred way to create objects outside the loop. Thanks for your answer.

Comment by Adolfo Rodriguez T on 2014-10-16:
Please mark the question as answered if you consider it resolved.

Comment by arennuit on 2014-10-16:
Not quite yet, but will do when ready. Thanks Adolfo ;)

Comment by arennuit on 2014-10-16:
Anyone interested in the answer should look at the first comment of the question. (the one comment by Adolfo).

Answer 2

You can use the sizeof() operator to determine the memory footprint of an object.

The accepted pattern would be to create the Service object, and do the .waitForExistence call once, outside the loop, to avoid the overhead. The overhead will be communication related - the nodehandle has to establish a connection with the service server through the ROS master.

---

Originally posted by paulbovbel with karma: 4518 on 2014-10-16

This answer was NOT ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by arennuit on 2014-10-16:
Thanks Paul, that helps.