On Mon, Jul 7, 2014 at 6:06 PM, Ryan Tanner <[email protected]> wrote:

> 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.
>

`def receive` is only called once, as the initial seed to context.become,
and since an actor has to be able to handle millions of messages per
second, and there may be millions of actors, the cost quickly adds up.


>
>
> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>>
>>> 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 [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to