Re: Limitations with v2 port implementation

2015-04-09 8:34 GMT-03:00 Peter Soetens <[email protected]>:
> Op 9-apr.-2015 11:57 schreef "Janosch Machowinski"
> <[email protected]>:
>>
>> Hey,
>> there is another issue with the current port implementation,
>> it might be related. The current implementation always searches
>> all known connections in a linear way and returns the first one
>> that has a sample.
>
> That is not entirely correct.  The search only happens when the current
> connection has no more data. This is indeed an extra penalty since each
> read on an empty port causes a search on all connections.

There are indeed two problems with the current behaviour (I'm not sure
whether it includes the one Janosch is experiencing, though):
 1. if the components do not manage to empty the "current" channel
then the other channels will never be read.
 2. if one has multiple active connections and means to empty all of
them, then there is a pretty high penalty of N^2/2 reads, since each
time you empty the channel, you go through the channel list to find
the next non-empty channel. That could very well be the actual non
linear complexity I hinted about in previous emails.

For 1.,  a strong never-worded assumption in RTT, the first thing
components should do is empty their connections. If you can't empty
your connection, you'll have to change the policies to make buffers
smaller (since, in any case, you *will* have trouble, changing how RTT
behaves in this case will just hide the problems until it hits you in
another way).
For 2, assuming that the N^2 iteration complexity is indeed the source
of the problem, one solution would be to:
 - have a per-channel 'active' flag. Any signalling channel returning
NoData or OldData will be marked as empty. Non-signalling channels are
always left active. The flags are stored in the channel manager to
avoid having to iterate through the channel list (which is costly)
 - use the signals in the channel manager to move channels back to
active when a signal is received. It would avoid the quadratic cost
when using non-polling or polling but signalling connections .
However, I would personally NOT accept any patch in this respect until
someone actually did some profiling to find out whether it actually is
the problem. No changes "for performance" that are not backed by
actual profiling data.
 - make all non-polling connections signalling since there's virtually
no cost in doing so (but don't propagate the signal to the task
context if it is not an event port)

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