ef87f7e1b9
Research across ractor, tokio, Erlang/OTP BEAM, Linux CFS, and libuv revealed that tick_all drained the entire mailbox per actor per tick, allowing one hot actor to starve all others on the same worker. - Add `actor_message_budget` to RuntimeConfig (default: 64 msgs/actor/tick) - Modify tick_all to break after budget messages, yielding to next actor - budget=0 restores unlimited (backward compatible) behavior - 3 new fairness tests validating hot-cold actor scenarios - New fairness benchmark group (cold_latency_under_pressure, throughput_by_budget) - Fix RuntimeConfig struct literals across workspace crates Inspired by BEAM's 4000-reduction budget and tokio's 128-op cooperative budget. All 45 tests pass (42 original + 3 new). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
32 lines
1.3 KiB
Markdown
32 lines
1.3 KiB
Markdown
# Baseline Benchmarks (pre-improvements)
|
|
|
|
## Latency (single-threaded)
|
|
| Benchmark | Time |
|
|
|-----------|------|
|
|
| spawn | 1.28 µs |
|
|
| message_roundtrip | 2.24 µs |
|
|
| send_fire_and_forget | 1.50 µs |
|
|
| inbox_creation | 1.63 µs |
|
|
|
|
## Throughput (single-threaded)
|
|
| Benchmark | Time | Throughput |
|
|
|-----------|------|-----------|
|
|
| single_actor/100 | 15.0 µs | 6.65 Melem/s |
|
|
| single_actor/1000 | 57.5 µs | 17.4 Melem/s |
|
|
| single_actor/10000 | 474.6 µs | 21.1 Melem/s |
|
|
| multi_actor/10x100 | 80.6 µs | 12.4 Melem/s |
|
|
| multi_actor/100x100 | 610.6 µs | 16.4 Melem/s |
|
|
| multi_actor/100x1000 | 6.10 ms | 16.4 Melem/s |
|
|
| ring/10 | 6.3 µs | 1.75 Melem/s |
|
|
| ring/100 | 99.9 µs | 1.01 Melem/s |
|
|
| ring/500 | 919.0 µs | 545 Kelem/s |
|
|
| spawn/100 | 33.5 µs | 2.99 Melem/s |
|
|
| spawn/1000 | 326.2 µs | 3.07 Melem/s |
|
|
| spawn/5000 | 1.69 ms | 2.96 Melem/s |
|
|
|
|
## Key Observations
|
|
- Single-actor throughput scales well: 6.65M → 21.1M msgs/s as batch size grows (amortized overhead)
|
|
- Multi-actor throughput lower due to iteration overhead across actors
|
|
- Ring throughput degrades with ring size (expected: each message traverses more actors)
|
|
- Spawn throughput steady at ~3M/s regardless of batch size
|
|
- Message roundtrip latency: 2.24µs (spawn + deliver + process + reply + deliver)
|