Re: Limitations with v2 port implementation

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.
.
> 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.

> 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).

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