Wait Free Realtime Publisher#461
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #461 +/- ##
==========================================
- Coverage 85.25% 81.89% -3.36%
==========================================
Files 17 21 +4
Lines 1397 1552 +155
Branches 132 152 +20
==========================================
+ Hits 1191 1271 +80
- Misses 120 186 +66
- Partials 86 95 +9
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
Is this ready for review? We can first discuss if the approach is fine, and then try to fix the backwards compatibility and windows build. |
|
@christophfroehlich sorry yeah I would like to have a review on it. I put it in draft with that intention, but I'm not totally familiar with the review process here. There seemed to be a weird inconsistency with the benchmark results that I wanted to circle back on (which is part of the reason why I kept this in draft), but I haven't found the time to do so. I suppose regardless, the current state of the PR should still be a net positive? I'll just take it out of draft. |
Ran benchmarks again with some updated settings, also with
|
|
This PR is stale because it has been open for 45 days with no activity. Please tag a maintainer for help on completing this PR, or close it if you think it has become obsolete. |
Background
RealtimePublisherclass uses locking mechanisms to publish data in a separate thread, but given it follows a single-producer single-consumer paradigm, we can create a wait-free implementation using theLockFreeQueuedata structure in this repo. This PR is an attempt to introduce this implementation.Changes
WaitFreeRealtimePublisherclass, which compared toRealtimePublisher:WaitFreeRealtimePublishertoRealtimePublisherRealtimePublisherto support benchmarking, and also adds publisher interface abstraction for benchmarks and testTesting
Benchmark Results
Settings:
Example Results: wait-free publishing side is 2 orders of magnitude faster than
RealtimePublisheron the producer-side. I'm still a bit confused by the publishing thread side: the other day I was also seeing an order of magnitude of messages that were published, so maybe this benchmark needs some tuning.Notes