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 determined by measurements that GC
overhead is your bottleneck.
Regards,
Roland
7 jul 2014 kl. 18:06 skrev Ryan Tanner <ryan.tan...@gmail.com>:
> Elsewhere you've said that there are performance downsides to context.become,
> specifically that this is the reason sender() is a function rather than doing
> something like def receive(sender: ActorRef): Receive = { ... }, which would
> eliminate the problem of closing over sender() in futures within a receive.
>
> Does the concern only come into play when calling context.become potentially
> thousands of times per second? I can see how that would probably lead to GC
> issues.
>
> On Monday, July 7, 2014 9:34:56 AM UTC-6, √ wrote:
> The time-overhead of calling become is very low. (I believe it's only one
> allocation aside from the PF).
>
>
> On Mon, Jul 7, 2014 at 5:32 PM, Richard Rodseth <rrod...@gmail.com> wrote:
> I was thinking time rather than space. I'm guessing the cost of swapping is
> not something I should worry about, but any reassurances or caveats are
> welcome. Receive block as partial function is so elegant!
>
>
> On Mon, Jul 7, 2014 at 7:54 AM, Richard Rodseth <rrod...@gmail.com> 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'm wondering about the overhead of become, and whether I should be
> considering the FSM stuff instead.
>
> Thanks.
>
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Cheers,
> √
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
