ObjectPoolAllocator
This is an extract from a bigger "Memory Optimizations" PR #675
It contains only the ObjectPoolAllocator part with a few exceptions:
RtpPacket::Parse()does return aRtpPacketinstance. In #675 it returned a shared pointer but since shared pointers are just needed for cloned packets (for retransmission), the former method does not need to create one.RtcpCompoundPacketis left as it was. This is, a new one is created when needed (this will be enhanced in a separate PR).
As per my tests I'm not seeing much difference with this and v3. There is maybe some noticeable CPU enhancement.
Please @nazar-pc , @Hartigan give it a try and instrument this if possible to see how it enhances comparing to v3. I'll do some more testing just to make sure this addition is worth it.
Performed performance unit tests:
| Parsed RtpPackets | ObjectPoolAllocator (sec) | new/delete (sec) |
|---|---|---|
| 10K | 0.0028 | 0.0039 |
| 100K | 0.027 | 0.038 |
| 1M | 0.26 | 0.33 |
| Cloned RtpPackets | ObjectPoolAllocator (sec) | new/delete (sec) |
|---|---|---|
| 10K | 0.0034 | 0.0049 |
| 100K | 0.033 | 0.049 |
| 1M | 0.33 | 0.48 |
ObjectPoolAllocator is definitely more performant as it reuses memory instead of freeing & re-allocating it.
NOTE: Currently measuring the CPU time differences with pools VS new/delete.
Converted to draft while re-testing re-profiling. Feel fee to try it out and review.
@Hartigan please send multiple comments as a review together rather than individually, it will reduce number of GitHub notifications everyone receives.
Which is the status of this PR?
It's ready to merge. It's working properly. Even though we may want to enrich he pool allocator in the future is a good starting point.
Ok?
Reminder: this PR needs love.
Yes, it's on my TODO
I'll revive this PR for the new year.