-
Notifications
You must be signed in to change notification settings - Fork 6
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Make pub_sub bench more realistic: use `String` payload instead of zero-sized-type The benchmark results are therefore not comparable before/after (they are 10% to 30% slower on my laptop). * Cache last published event and let subscribers receive it upon subscription. Closes #86 * Try to use dashmap This fixes the performance regression for me, but we need to think whether that's worth the dependency tradeoff. * Split `Event` and `CacheableEvent` With a small trick (that unfortunately leaks to a public type) we were able to implement a kind of specialization [1] with perfect behavior: `Event`s don't pay the price for caching, and it is not possible to subscribe_and_receive_latest() to bare `Event`s. Also, it means that we didn't have to add bounds to `Event` [2]. [1] I thought the orphan rule would prevent us from adding the blanked implementation, but not! [2] I've sneaked in the removal of `'static`, but that's mostly aesthetic: `std::any::Any` requires it anyway. * Extend pub_sub benchmark with CacheableEvent type * Use DashMap also for the subscriber callbacks map ...now that we have it in the dependency tree anyway. Allows us to remove the `RwLock` which in turn allows us to deduplicate subscribe_recipient() vs. subscribe_and_receive_latest(). Let's think about the possible situations of "publishing the first message" vs. "just subscribing and getting latest". * Drop `dashmap` and reinstate `RwLock` again, but try to lock efficiently * Deduplicate subscription code into EventSubscribers::subscribe_recipient() * Back to dashmap, but keep deduplication and extend comments * Update src/lib.rs Co-authored-by: Matěj Laitl <[email protected]> --------- Co-authored-by: Matěj Laitl <[email protected]>
- Loading branch information
Showing
5 changed files
with
140 additions
and
16 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters