44 lines
2.3 KiB
Markdown
44 lines
2.3 KiB
Markdown
|
### 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.
|