dtpc: performance issue with small bundles in large aggregator windows

[zebastian]

insertRecord currently recomputes totalLength with estimateLength for every new bundle over all bundles already in there (n-squared issue).
Instead the outAdu could hold the aggrLength as a property and the aggrLength is added the current bundles length on insert and then this pre-computed one is used.

[zebastian]

i have a benchmark for dtpc which shows this,
but it depends on not-yet-merged changes of #74

[250MHz]

Feel free to share the benchmark. The idea behind #74 sounds good, so I expect someone will review it eventually

[zebastian]

here the results:

with current code:

========================================
Test 1: 50000 x 50B records, large-aggr profile
  cycles=50000 reclen=50 topic=11 profile=3
========================================
--- Sender ---
Time (seconds): 9
Total payloads: 50000
Total bytes: 2500000
Throughput (bytes per second): 277777
Sender wall time: 9406 ms
--- Receiver ---
Time (seconds): 10
Throughput (bytes per second): 250000
Final tally of payloads received: 50000

with patch:

========================================
Test 1: 50000 x 50B records, large-aggr profile
  cycles=50000 reclen=50 topic=11 profile=3
========================================
--- Sender ---
Time (seconds): 4
Total payloads: 50000
Total bytes: 2500000
Throughput (bytes per second): 625000
Sender wall time: 3707 ms
--- Receiver ---
Time (seconds): 5
Throughput (bytes per second): 500000
Final tally of payloads received: 50000

--> sender time reduced by a factor of ~2.5 for 50000 records in 1 adu.

[zebastian]

@250MHz
see code for n-squared-issue-resolve and the benchmark in the pull request attached.