messages sent to actor are not boxed anymore

[Kannen]

While navigating inside the code I realized that every message sent to local actor are boxed.

So I made a set of simple changes so that message sent to actor are directly sent to the mpsc channel without being boxed. This avoid one allocation per message.

The benchmarks show improvements. Moreover I think a more realistic benchmark would show much more improvement as avoiding the allocation should enhance cache locality during real code execution.

In this pull request I have used unsafe code, as it avoid to do a redundant type_id check, but it can implemented with 100% with safe code, at the cost of a call to Any::downcast_ref at each message sent.

[Kannen]

I have written some benchmarks, it improve OutputPort message dispatching by 50% and concurrent processing and message sending by 22%.

[Kannen]

Just to show you how interesting in those changes I propose:

• all messages sent to output ports are delivered
• removal of some race conditions inside pg

And speed enhancement, this is the comparison of the main branch with the fusion of the changes I propose:

     Running benches/actor.rs (target/release/deps/actor-8267de2bad91941e)
Creation of 100 actors  time:   [621.28 µs 623.51 µs 625.64 µs]
                        change: [-5.9816% -5.5918% -5.2311%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) low mild

Benchmarking Creation of 10000 actors: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 8.0s, or reduce sample count to 60.
Creation of 10000 actors
                        time:   [71.562 ms 71.927 ms 72.288 ms]
                        change: [-4.3784% -3.7695% -3.1403%] (p = 0.00 < 0.05)
                        Performance has improved.

Waiting on 100 actors to process first message
                        time:   [28.116 µs 28.207 µs 28.308 µs]
                        change: [-16.420% -12.757% -9.7980%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 10 outliers among 100 measurements (10.00%)
  2 (2.00%) low mild
  4 (4.00%) high mild
  4 (4.00%) high severe

Waiting on 1000 actors to process first message
                        time:   [212.16 µs 213.01 µs 213.91 µs]
                        change: [-3.6355% -1.9731% -0.7051%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 6 outliers among 100 measurements (6.00%)
  6 (6.00%) high mild

Waiting on 100000 messages to be processed
                        time:   [29.750 ms 29.920 ms 30.114 ms]
                        change: [-18.567% -17.969% -17.292%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

Benchmarking Waiting on 100000 messages to be sent and processed concurrently: Collecting 100 samples in estimated 5.4903 s (200 itWaiting on 100000 messages to be sent and processed concurrently
                        time:   [27.199 ms 27.341 ms 27.493 ms]
                        change: [-26.341% -25.865% -25.322%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 12 outliers among 100 measurements (12.00%)
  11 (11.00%) high mild
  1 (1.00%) high severe

Benchmarking Waiting on 1000 messages to be sent on output port to 100 actors: Collecting 100 samples in estimated 5.2824 s (500 itWaiting on 1000 messages to be sent on output port to 100 actors
                        time:   [10.123 ms 10.139 ms 10.155 ms]
                        change: [+0.6423% +1.3110% +1.8904%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 6 outliers among 100 measurements (6.00%)
  1 (1.00%) low mild
  4 (4.00%) high mild
  1 (1.00%) high severe

     Running benches/async_traits.rs (target/release/deps/async_traits-4e1c090e51e5824e)
Benchmarking Waiting on 50 messages with large data in the Future to be processed: Collecting 100 samples in estimated 5.6369 s (20Waiting on 50 messages with large data in the Future to be processed
                        time:   [92.790 µs 94.889 µs 96.931 µs]
                        change: [-14.356% -12.087% -9.8323%] (p = 0.00 < 0.05)
                        Performance has improved.

     Running unittests src/lib.rs (target/release/deps/ractor_cluster-5a0dcb660cf38e6f)

[codecov]

Codecov Report

❌ Patch coverage is 97.12230% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.62%. Comparing base (a5e0c65) to head (b94ee94).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
ractor/src/message.rs	85.71%	2 Missing ⚠️
ractor/src/actor/actor_properties.rs	98.96%	1 Missing ⚠️
ractor/src/thread_local/inner.rs	88.88%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #370      +/-   ##
==========================================
+ Coverage   82.48%   82.62%   +0.14%     
==========================================
  Files          71       71              
  Lines       12919    12984      +65     
==========================================
+ Hits        10656    10728      +72     
+ Misses       2263     2256       -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Kannen]

The difference shown in code coverage are due to the fact I have move around some piece of code from one file to the other. This does not change the number of branches tested.
The lacking test all relates to the "cluster" feature and I do not know yet how to use this feature and how even less how to test it.

[slawlor]

rebase and this should go away

[slawlor]

Given this is a semver break anyways, we'll need a major release to do this, and should just get rid of BoxedMessage.

It's a poor name given the message would no longer be boxed in this case.

[slawlor]

why does this need to be a trait? Is this just for ergonomics? These seem like blanket impl helper functions, I don't see the need for this here

[slawlor]

nevermind looking more closely at the PR, I see the reasoning.

[slawlor]

@Kannen I can't reproduce your savings (outside maybe of output ports), but I'm dubious if this saves much on processing speed of messages in reality. Have you run the benchmarks multiple times to avoid jitter? You need to be doing it on a quiet host too so there's limited contention.

See my results in #387, which shows there's little difference in the regular suite of tests.