Performance of MotionController::RecorderDataAddressSet

RapidCode API
1

Configuring Recorders

I’m doing a performance analysis of our application, and I’m looking for things that are taking a Long Time™. One of the items that came up hot on my list is an API call to configure a recorder.

After I start the network and acquire all the Axis and NetworkNode objects. Then, I configure a number of recorders in order to have an up-to-date value of a number of per-axis items (e.g. actual position, actual velocity, etc.). I’m doing this in order to prevent the need to make RSI API calls that take some time (likely due to thread synchronization).

Anyway, it seems as though setting an address for a recorder item is taking “some” time. I am configuring 6 recorders with 188 individual items. I’m calling MotionController::RecorderDataAddressSet(...) in very close succession all those times, and the total time within that function is 13.76 seconds (i.e. 73 ms/call).

(This data came from a sampling profiler, so the numbers are approximate, but probably representative.)

Would you consider this a “long” time? It seems like a long time to me, but I don’t really know what it’s doing.

Is it possible that I’m doing something wrong (or making the call at the wrong time) that could result in poor performance like this?

2

We keep tabs on execution time, but we were not testing that method. (Now added.)

I’ve added to our tests and I’m seeing ~5.7ms per call here. I’m not sure I’d call that Long Time™, but it is one of the longer ones in our API.

We’re less sensitive about configuration method’s speed. A solution would be to add a method where you could give us an array of addresses to record, which would cut your time to to 6/188 of its current time. It does seem like 1.1s (188 * 5.7ms) to configure the recorders is excessive. We’ll discuss internally.

1 Like
3

IDK how much extra time was induced by my profiling. Probably more than nothing.

Another possibility is that I’m doing something out of order or at The Wrong Time™. Are there things I can control that could impact the performance of these API calls?

4

The timing ran on a couple other test agent computers and ranged for 4.4ms to 8.1ms.

I don’t think there’s anything you could do to change the performance. It’s always The Right Time™.

Can you noticeably tell when the recorders are configuring? It seems like it could be taking ~1.5s. Recorder configuration could probably be done from an independent thread, but not sure that’s worth the effort/risk.

5

Would it make any difference at all if there were ~30 nodes on the network? I’m trying to test with lots of nodes to get some worst case scenario results…

What if there were other threads doing things? (I don’t really expect that to be happening, but it’s possible.)

6

In our case, everything else is waiting for this configuration to take place, so threading off the process isn’t going to help.

In my case, I’m seeing the configuration take on the order of 13 (extra) seconds to complete. It’s noticeable, but it’s not a show stopper.

7

We’ve added the following method (to be in the next release, 10.3.8) which will allow you to configure 32 addresses with one call. This should speed up your initialization times. Thanks for the suggestion!

>     /// @brief Setup multiple addresses to record at once.
>     /// @param recorderNumber The number of the recorder to configure.
>     /// @param addresses A pointer to an array of 64-bit host addresses to be recorded.
>     /// @param addressCount The number of elements in the addresses array.
>     /// @see RecorderDataAddressSet
>     virtual void RecorderDataAddressesSet(int32_t recorderNumber, const uint64_t* const addresses, int32_t addressCount) PURE_VIRTUAL;
1 Like