Closed laplab closed 1 year ago
For context, this is a version with a separate high-priority message channel. It has likely
/ unlikely
put in (hopefully) the right places and includes a slightly biased reimplementation of tokio::select!
.
On Linux, the results are a little bit more decisive. 9 out of 24 benchmarks are improved and 15 are regressed. I expected all of the benchmarks to be in regression, it is a little bit strange to see 9 of them improved.
12 out of 15 regressions are less than 10%. I am hesitant to investigate them more closely, since this can be noise.
The 3 remaining regressions are:
only_command/one_to_one/one_instance/10
25% worseonly_command/one_to_one/one_instance/3
25% worseonly_command/round_robin/one_instance/3
12% worseI think it also makes sense to quickly implement an idea with one simple Option
for UpdateConfig
message instead of a separate channel. It looks like the most efficient way to implement the whole thing in terms of overhead, so it can be an interesting baseline to compare against.
I think it also makes sense to quickly implement an idea with one simple Option for UpdateConfig message instead of a separate channel. It looks like the most efficient way to implement the whole thing in terms of overhead, so it can be an interesting baseline to compare against.
It also requires Notify
or, in order to avoid dependence on tokio in this place, https://docs.rs/futures-intrusive/latest/futures_intrusive/sync/struct.GenericManualResetEvent.html).
After some offline discussion I have implemented prioritisation in the RingBuf
, which is used by GenericChannel
under the hood. The is very proof-of-concept version because it does not handle sending multiple priority messages at once and sometimes makes the benchmark panic with 'called before close()', elfo-core/src/mailbox.rs:154:42
, which I was not able to debug just yet.
It seems that there are no regressions with more than 10% difference. In fact, the biggest regression is 8% and the others are below 5%.
Closing this, since we decided that we are not quite ready to introduce message prioritisation just yet. We will be switching from request()
to pure send()
for UpdateConfig
messages however, which should provide significant boost in config updates (which was the original intention behind this PR).
Benchmarks on my Mac are a little bit all over the place. I will try to get more consistent results on a Linux machine.
Comparison on Mac
``` $ critcmp master patch group master patch ----- ------ ----- only_command/one_to_one/one_instance/1 1.00 315.2±128.71ns 3.0 MElem/sec 1.37 432.3±235.58ns 2.2 MElem/sec only_command/one_to_one/one_instance/10 1.00 3.0±1.74µs 3.2 MElem/sec 1.14 3.4±1.84µs 2.8 MElem/sec only_command/one_to_one/one_instance/11 1.00 2.9±1.37µs 3.7 MElem/sec 1.38 3.9±2.04µs 2.7 MElem/sec only_command/one_to_one/one_instance/12 1.65 6.7±1.92µs 1760.5 KElem/sec 1.00 4.0±2.21µs 2.8 MElem/sec only_command/one_to_one/one_instance/2 1.00 780.4±297.81ns 2.4 MElem/sec 1.10 857.3±434.40ns 2.2 MElem/sec only_command/one_to_one/one_instance/3 1.00 838.4±252.47ns 3.4 MElem/sec 1.24 1039.4±408.89ns 2.8 MElem/sec only_command/one_to_one/one_instance/4 1.08 1448.4±391.31ns 2.6 MElem/sec 1.00 1344.5±678.08ns 2.8 MElem/sec only_command/one_to_one/one_instance/5 1.18 2.0±0.60µs 2.4 MElem/sec 1.00 1711.0±626.59ns 2.8 MElem/sec only_command/one_to_one/one_instance/6 1.04 2.0±0.87µs 2.8 MElem/sec 1.00 1966.1±820.88ns 2.9 MElem/sec only_command/one_to_one/one_instance/7 1.24 2.4±1.33µs 2.7 MElem/sec 1.00 1962.0±976.26ns 3.4 MElem/sec only_command/one_to_one/one_instance/8 1.00 2.4±1.12µs 3.1 MElem/sec 1.08 2.6±1.34µs 2.9 MElem/sec only_command/one_to_one/one_instance/9 1.00 2.8±1.34µs 3.1 MElem/sec 1.09 3.0±2.16µs 2.9 MElem/sec only_command/round_robin/one_instance/1 1.00 400.9±205.79ns 2.4 MElem/sec 1.03 414.9±240.49ns 2.3 MElem/sec only_command/round_robin/one_instance/10 1.11 8.2±2.51µs 1187.5 KElem/sec 1.00 7.4±1.82µs 1321.3 KElem/sec only_command/round_robin/one_instance/11 1.12 8.7±3.22µs 1229.2 KElem/sec 1.00 7.8±2.24µs 1373.7 KElem/sec only_command/round_robin/one_instance/12 1.05 8.5±2.52µs 1379.5 KElem/sec 1.00 8.1±2.38µs 1454.2 KElem/sec only_command/round_robin/one_instance/2 1.08 1124.4±619.92ns 1737.0 KElem/sec 1.00 1037.4±508.90ns 1882.8 KElem/sec only_command/round_robin/one_instance/3 1.00 1310.8±501.58ns 2.2 MElem/sec 1.57 2.1±1.50µs 1427.2 KElem/sec only_command/round_robin/one_instance/4 1.00 2.5±0.95µs 1593.9 KElem/sec 1.05 2.6±0.88µs 1521.4 KElem/sec only_command/round_robin/one_instance/5 1.00 3.1±1.16µs 1577.2 KElem/sec 1.06 3.3±1.31µs 1487.0 KElem/sec only_command/round_robin/one_instance/6 1.09 4.6±1.48µs 1283.1 KElem/sec 1.00 4.2±1.35µs 1397.1 KElem/sec only_command/round_robin/one_instance/7 1.08 5.5±1.53µs 1252.6 KElem/sec 1.00 5.1±1.76µs 1347.6 KElem/sec only_command/round_robin/one_instance/8 1.08 6.4±2.07µs 1222.8 KElem/sec 1.00 5.9±1.37µs 1324.5 KElem/sec only_command/round_robin/one_instance/9 1.05 7.3±1.99µs 1208.1 KElem/sec 1.00 6.9±1.65µs 1265.8 KElem/sec ```