3e504d3969
Ran through a few passes of the 'happy path' with the debugger, ran flamegraph analysis: we are very much overdoing the atomic ring buffer channels. They may be fast for concurrency across threads, but we don't necessarily need that for every occasion.
2.3 KiB
Profiling and Benchmarking
-
Research as to modern art on benching and profiling
- Implement an MVP here.
- Bench/profile against a suite of tests selected for generality across actor framework usecases
-
Identify hot paths and bottlenecks
- e.g. pretty sure the router is a major bottleneck, what else
- follow through the entire message cycle: Parent process -> Convert to swactor::Message/Envelope -> Router -> Delivery -> Processing -> etc. Identify every small detail on which you may be able to improve, any unneeded processing or branching
-
(optional) Visualization tools:
- make some pretty stuff for tracing messages, actor activity, router activity, etc.
Usage
-
After benching and profiling, cleaning up the most egregious wrongdoings we will:
- actually implement our own projects in the framework, ones I actually find useful personally
-
Optimization pipeline:
- Once we have well-established benches and profiles for general cases, build a set of tools that can auto-optimize for given use cases. Tuning, for example, the channel buffers, router behavior, message consumption behavior, etc.
Chores
- go over all the FIXMEs littered about. Add comments.
- add misc features as they come up. Prefer tools for understanding execution flows, visualizing flows, and adding robustness, over ergonomics. Better to be slightly clunky but fast and optimized, than vice versa.
Far future
- make language bindings. e.g., an npm package, python bindings, etc.
Optimization
- Localize actors and inboxes:
-
Because the entire runtime is message driven, the happy path must be fast. Even lock free, when we have to go through several calls of an atomic ring buffer in order to process a single message, its unnecessary. Parent process -> router -> actor -> router -> inbox -> parent process; every transfer going through an atomic buffer.
-
to do this, design heavily around a localized worker thread. Actors on a working thread should have their inbox localized, they should be 'sticky' to that thread (FILO queue?), and we should route messages based on core locality. Future optimizations can include a tunable algorithm that puts actors that frequently communicate together on the same thread.
-