Re: Limitations with v2 port implementation

On Apr 08, 2015, at 09:46, Sylvain Joyeux <[email protected]> wrote:

> 2015-04-08 8:08 GMT-03:00 S Roderick <[email protected]>:
>> 1) performance when writing to output ports is much slower in v2 than v1, as essentially the update occurs to multiple connection objects in v2 (in v1 it occurred to one connection object). One of our components has a 450% slow down when writing to its eight (8) output ports.
> I also noticed slowdowns when a single port was connected to a lot of ports.

Yeah, one of our systems is ~15% slower in v2 than v1. Not all of that is ports, but they are definitely contributing. :-(
.
>> 2) flow status does not cover the use case where you want a single connection object, and don’t care when a connection is made nor when a value is written (i.e. you don’t care about “flow”).
> I would argue that if you don't care about *at all* flow, it probably
> means that you want something else than a port, such as a property or
> attribute. The use case you describe here reeks of attributes.

> 
> But read on.
> 
>> One of our examples here is static configuration data (say the name, model or serial number, of a device, or a robot’s number of DOF).
> That is *definitely* the job of an attribute.

That is a perfectly valid alternative. But the nice thing about ports is that the deployer automagically connects components, which doesn’t happen with attributes.

We also have other use cases like this, not all of for which attributes *may* fit.

>> When the source component is configured or started, it writes the appropriate data to the port. If a connection is made in the future (say by a GUI, or by a reporting component that has dynamically created ports) then v2 ports will not present the value that was previously written (I believe as there has been no “flow” of data since the connection was made). In this use case, we believe that the v1 single-connection-object semantics made more sense as connected peer components are only interested in the value, and not when it was written nor whether it has been updated (i.e. they don’t care about flow).
> 
> You can request getting the last value written on connection by
> setting the 'init' policy to true, but that requires the output port
> to keep the last written value explicitely (which is not the default
> AFAIK). That's how we keep track of the current task state in Rock
> (over orogen's 'state' port).

Agreed, but it doesn’t solve the performance issue.

Cheers
S

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev