Hi Ryan,
the same caveat applies to both context.become and FSM: every state change
involves an object allocation. In those cases where that is relevant you would
be better off using mutable fields to avoid allocations altogether, but I would
not start worrying about this until you have determi
What kind of overhead?
On Mon, Jul 7, 2014 at 4:54 PM, Richard Rodseth wrote:
> I'm considering using become(processing(params)) in some of my short-lived
> "job" actors, so that the params are available when the job completes, yet
> the job can be started separately from its creation.
>
> So I
I'm considering using become(processing(params)) in some of my short-lived
"job" actors, so that the params are available when the job completes, yet
the job can be started separately from its creation.
So I'm wondering about the overhead of become, and whether I should be
considering the FSM stuf
