These are chat archives for akkadotnet/akka.net

7th
Feb 2017
Andy Maesen
@arxae
Feb 07 2017 00:11
Hello, i have 2 quick questions. 1. Which of the actors is preffered? (ReceiveActor or TypedActor) and 2. Is it better to keep a globally accessible reference to an actor, or use the ActorSelection method?
Bartosz Sypytkowski
@Horusiath
Feb 07 2017 05:55
@arxae
  1. Use ReceiveActor. TypedActors are inefficient, very limiting and should be removed.
  2. IActorRef gives more power and it's faster. But once actor gets stopped, it's no longer valid - for good or bad, depending on your use case.
Maxim Cherednik
@maxcherednik
Feb 07 2017 05:56
@Horusiath ReceiveActor slow as well ?
and what do you mean: it should be removed?
Bartosz Sypytkowski
@Horusiath
Feb 07 2017 05:57
I meant TypedActors ;)
Caleb Vear
@caleb-vear
Feb 07 2017 05:57
@Horusiath cool, thanks for the clarification.
Maxim Cherednik
@maxcherednik
Feb 07 2017 05:58
so this one is ok: public abstract class ReceiveActor : UntypedActor, IInitializableActor ?
seems like Untyped:)
Bartosz Sypytkowski
@Horusiath
Feb 07 2017 05:59
UntypedActor is ok, TypedActor is bad (as you cannot build state machines and it relies heavily on reflection)
last time I've checked, TypedActor was on average 10x slower than UntypedActor
Maxim Cherednik
@maxcherednik
Feb 07 2017 06:01
Yeah - i ve seen this before. Was just a bit surprised about 'Use ReceiveActor. TypedActors are inefficient,'
Ricky Blankenaufulland
@ZoolWay
Feb 07 2017 07:38
@Danthar Thanks for your input. Yes, I am a bit worried about implementing such a stuff on mailbox level and I guess there are many things which will can be done wrong. But also I could not come up with a proper flow how to handle it by the actor itself.
Now that you point again in that direction I think maybe I could have two stages of messages. The first one, plan-a-refresh, will set a flag on the actor. If another plan-a-refresh message occurs while that flag is true, it will be ignored. The first message but will not also set the flag but self-tell a do-a-refresh message. That one will be at the end of the actor mailbox queue and all already queued plan-a-refresh messages will be ignored due to that flag. The do-a-refresh message will when do it and reset the flag.
I am doing this because there are external events which will cause like 50 to 100 actors to notify this one actor to do a refresh and it would be nice to do the refresh after the last message or at least not as often as that number.
Arjen Smits
@Danthar
Feb 07 2017 07:42
@ZoolWay maybe using the ReceiveTimeout feature would be enough ?
If your actor receives alot of messages throughout. You could also forward the refresh messages to a seperate actor. That utilizes the receive timeout functionality to detect when a surge of refresh messages has ended.
and have it send the actual refresh command
Ricky Blankenaufulland
@ZoolWay
Feb 07 2017 07:47
Oh, I think that's a great idea!
I have not used ReceiveTimeout before but your idea sounds great and I can balance the time to see what fits best. Thanks @Danthar !
Arjen Smits
@Danthar
Feb 07 2017 08:36
no problem :+1:
Aaron Stannard
@Aaronontheweb
Feb 07 2017 16:45
@maxcherednik ReceiveActors compile their receives when they're first used
so you don't get the dynamic method invocation overhead that you normally would with an anonymous method or delegate
so its performance is pretty close to an untyped actor
when CSharp 7 lands I'm going to bet that the UntypedActor with built-in pattern matching will be the new hotness