Performance Improvements

[slawlor]

Actors initially were taking an excessive amount of memory for each instance. This is a tracking issue to reduce memory and increase processing time latencies in the actor framework.

Some ideas

• Remove dashmaps from ActorProperties Actors were taking an excessive amount of memory upon creation. #260
• Investigate other fat utilizations in ActorProperties
• Remove monitors (they're kinda useless) in favor of just straight supervision (saves 2 maps) Actors were taking an excessive amount of memory upon creation. #260
• Remove stop notifier being a broadcast sender Changed stop notifier to a Notify More memory improvements, but smaller. No API changes #261

[slawlor]

Moving the bounded channels from mpsc::bounded(1) to oneshot()s seems to be able to save us an additional ~18% in memory and more spawning and message processing performance too. #263

[cerceris]

There is another important performance metric: how fast the framework can create actors. Many actors. In practice it determines how smooth and painless would be the "warming" process, or similar bursts.

[cerceris]

Also, the actor model in general appears to be pretty AI / code generator friendly. At the same time, plenty of boilerplate stuff is a feature. So DSL(s) and tools for constructing actor-based systems is what we'd like to have. We = devs and users of the framework.

[slawlor]

There is another important performance metric: how fast the framework can create actors. Many actors. In practice it determines how smooth and painless would be the "warming" process, or similar bursts.

So for this specifically, there are benchmarks creating up to 10k actors in a tight loop, and blocking until they all start. https://github.com/slawlor/ractor/blob/main/ractor/benches/actor.rs#L102-L113

So DSL(s) and tools for constructing actor-based systems is what we'd like to have

Are you referencing something like a code plugin to an IDE? Or maybe an AST that could build this kind of stuff? Do you have any examples to what you're referring to here?

[cerceris]

I've been developing a similar framework, actix based. Well designed actor system is, as I believe, could be a kinda 'silver bullet'. Back to your question, the actors themselves (or 'tasks' in my context) are very similar, with decent amount of boilerplate for the basic, common stuff. I'm thinking about a code generator, or an AI/LLM assistant they can generate the 'scaffolding' actor code from a formal description. Like: make configurable timers A, B, C and the respective message handlers; make message handlers for X, Y, Z; make subtask links for another actors; and so on. I don't have a concrete example of the actor code generator, but I personally hope to find time to address this topic.

[cerceris]

There are a lot of things to do for ractor. The most important thing: do not stick to the Erlang implementation / concept. Be more flexible. Do not limit yourself. Do not do the blind "porting Erlang --> ractor". Also. Do not repeat actix mistakes. I like actix. And actix-web. But where are the actors? When I opened their examples several years ago, 'async fn my_get_for this_path_handler_bla_bla(...)". Seriously? I love actix and its derivatives. But now it's an abandoned project. There are well-known limitations for which we had to invent "workaround patterns". Professor Kim has been developing yet another collection of frameworks. So ractor could be the thing. If done right, of course.

[cerceris]

ractor is supposed to be eventually an actor framework having a comparable importance and significance as tokio has a level below. At least, if you don't have it in mind, I don't know, I would have not even started. The actor model and a great framework for it written in Rust can be a 'silver bullet' for a very broad scope of systems and problems. Proved.

[slawlor]

There are a lot of things to do for ractor. The most important thing: do not stick to the Erlang implementation / concept. Be more flexible. Do not limit yourself. Do not do the blind "porting Erlang --> ractor". Also. Do not repeat actix mistakes.

So first off thank you for the feedback. I would like to address some of this.

Firstly the general inspiration for this framework was Erlang, given Erlang being one of the longest-running, stable actor frameworks around. However it is not at all a direct port of any kind. I hope that's evident, but we did keep syntax and naming consistent so people coming from Erlang, looking for better performance, would find this familiar and a relatively easy transition. However aside from some of the modules in OTP, ractor is very very different and I do not view Erlang as a limiting factor in any way.

RE Actix. I believe we're sufficiently different and not "repeating those mistakes". @robjtede can speak to this, since he's the defacto maintainer of actix these days, but actix is dead and the recommendation for an actor framework replacement is ractor. Full stop. Actix web is very much alive, and awesome, but is completely independent and has been for a long time now. ractor is running production workloads at scale today, so aside from the cluster components, I'm fine endorsing it for production work anywhere.

In general: I'm always open to contributions so if you'd like to ever put up a PR or change, please feel free to do so, and I'll do my best to review and merge should it be a good fit.

ractor is supposed to be eventually an actor framework having a comparable importance and significance as tokio has a level below

I don't believe I've ever stated this, and while this might be great in the long run, actors are decidedly opinionated and will never reach the level of tokio at-large, and I'm fine with that.

If you'd like to discuss this further, please open a separate issue for tracking.

[cerceris]

I meant "tokio-level" among "actor frameworks". But if you don't have such ambitions, then I made a false assumption. Sorry. I'll be studying ractor more deeply for sure. If I had any chance to contribute, I would do.