1.x: replay request coordination reduce overhead#3470
Conversation
00c1727 to
0d6cf2d
Compare
|
I've updated the code to have O(1) subscription/unsubscription cost as well. The program from #3469 now produces stunning results: (The numbers could be actually higher but Windows' timer resolution is about 3ms at best). |
0d6cf2d to
910000c
Compare
|
I've updated the code to avoid the synchronized block on each replay attempt in case the cached version of the InnerProducers is still the same as the set's version. |
|
I haven't reviewed the changes in detail yet but I do notice that OpenHashSet doesn't have any dedicated unit tests. |
910000c to
464568d
Compare
|
I've added a unit test for |
464568d to
53a74e4
Compare
|
Strangely, the test doesn't crash with Java 8. Must be some difference between what type for-each extracts. |
|
@akarnokd needs rebase on latest |
|
Thanks. Working on it. |
713fbe1 to
b361d7a
Compare
|
Rebased. |
|
I like this a lot, and the results are really impressive. Code looks good to me, cleaner than the previous implementation too. 👍 |
|
I finally find some time to review this one, sorry for the delay. |
Reported in #3469.
This change will make sure whenever a new subscriber arrives, the
request coordination doesn't scan every other subscriber unnecessary.
(They will trigger a manageRequests individually anyway).
Unfortunately, I can't make the subscription registration constant (via a HashSet) because that would slow down the dispatching loop (which is quite expensive to for-each over compared to a plain array).
Note also that this will likely conflict with #3454.
I get the following numbers with the program in #3469.