Revision history [back]

You're right that tf was designed focusing on ease of use. I'll comment on each of your points.

1. We have tested using a binary tree structure for lookup which is faster for arbitrary lookups. However we observed actually higher lookup times and more overhead on maintaining the structure than the linked list. The maintenance of the tree is obviously higher overhead as you need to insert into the tree and prune in the tree. And as most data comes in in sequence it never needs to walk the tree when inserting. And pruning a sorted linked list is also trivial. For the lookup times most of the time queries are very close to the front of the list and although the lookup complexity is O(n/2) where n is the length of the list. In most use cases it is much faster since it walks the list from the newest data.
2. Names are stored in a hash map, which does not require a search. (yes it is not realitme safe to be processing strings, but names mean a lot more to developers and users than numeric ids. We tested originally using numeric frame ids and it was wholly undebuggable.
3. When sending data on the same machine the kernel is quite optimized and effectively passes the data through shared memory over the loopback interface. I've never seen tf data be a bottleneck performance wise on loopback. (It does become a problem over wifi)
4. I'm not sure what you mean by this bullet point. Interpolation is required estimate transforms across unsyncronized datasources. As well as allowing lower publish rates for data which is able to reflect the bandwidth of the signal of a link. (Fast moving transforms require high speed publishing. Low speed links can publish infrequently but remain accurate. Without this every link would be required at every timestep wanted to query, so it's actually a significant performance boost.) And extrapolation is discouraged and disabled by default.

Overall there are things which can be optimized however in typical testing on a desktop a tf lookup is measured in microseconds so we haven't worked on optimizing it further. There are many other things to optimize. The biggest bottleneck, mentioned earlier, is bandwidth usage over wifi. And there are several different techniques for downsampling and forwarding data over a limited bandwidth link.

You're right that tf was designed focusing on ease of use. I'll comment on each of your points.

1. We have tested using a binary tree structure for lookup which is faster for arbitrary lookups. However we observed actually higher lookup times and more overhead on maintaining the structure than the linked list. The maintenance of the tree is obviously higher overhead as you need to insert into the tree and prune in the tree. And as most data comes in in sequence it never needs to walk the tree when inserting. And pruning a sorted linked list is also trivial. For the lookup times most of the time queries are very close to the front of the list and although the lookup complexity is O(n/2) where n is the length of the list. In most use cases it is much faster since it walks the list from the newest data. The other thing to keep in mind is that although the user/developer mostly sees the lookup times. There are many more insertions and background updates than lookups.
2. Names are stored in a hash map, which does not require a search. (yes it is not realitme safe to be processing strings, but names mean a lot more to developers and users than numeric ids. We tested originally using numeric frame ids and it was wholly undebuggable.
3. When sending data on the same machine the kernel is quite optimized and effectively passes the data through shared memory over the loopback interface. I've never seen tf data be a bottleneck performance wise on loopback. (It does become a problem over wifi)
4. I'm not sure what you mean by this bullet point. Interpolation is required estimate transforms across unsyncronized datasources. As well as allowing lower publish rates for data which is able to reflect the bandwidth of the signal of a link. (Fast moving transforms require high speed publishing. Low speed links can publish infrequently but remain accurate. Without this every link would be required at every timestep wanted to query, so it's actually a significant performance boost.) And extrapolation is discouraged and disabled by default.

Overall there are things which can be optimized however in typical testing on a desktop a tf lookup is measured in microseconds so we haven't worked on optimizing it further. There are many other things to optimize. The biggest bottleneck, mentioned earlier, is bandwidth usage over wifi. And there are several different techniques for downsampling and forwarding data over a limited bandwidth link.