tellus comparison benchmarks
Messaging throughput of tellus against kameo and ractor, higher is better.
- Tag
- manual-32706028064
- Commit
- 927bd820d3206929926e56b278beb138b961046a
- Date
- 2026-08-24T08:29:19Z
- Versions
- kameo 0.22.2, ractor 0.16.5, tellus 0.1.0
- CPU
- AMD EPYC 9V74 80-Core Processor (4 cores)
- OS
- Linux 6.17.0-1022-azure
- Toolchain
- rustc 1.98.0 (88d9e12ae 2026-08-18)
Read this before drawing conclusions
- tellus's
receive is synchronous; kameo's and ractor's handlers are async fn.
tellus therefore avoids allocating and polling a future per message, but cannot await inside receive.
This is a capability difference, not only a speed difference, and it favours tellus on exactly these microbenchmarks.
- tellus's mailbox is statically typed; the others erase message types, costing an allocation
and a dynamic dispatch per message that tellus does not pay.
- Competitors are configured for speed, not defaults. kameo runs without
tracing
and ractor without message_span_propogation, both of which add per-message instrumentation that
tellus has no equivalent of. This biases the setup in the competitors' favour.
- Messaging microbenchmarks only. Nothing here speaks to supervision, distribution,
ergonomics, memory use or production readiness. kameo and ractor are mature, feature-rich frameworks; tellus is
under active development and does far less.
- On CI these run on a shared 2-core runner, so absolute figures are not representative of real
deployments. Only the relative comparison within a single run is meaningful.
- Written and run by tellus's maintainer. The full methodology and benchmark source are in the
repository; corrections are welcome.
fan_out (8)
fan_out (32)
flood
ping_pong (1)
ping_pong (8)