Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider changing default capacity of actor's mailbox #293

Closed
qwwdfsad opened this issue Mar 20, 2018 · 3 comments
Closed

Consider changing default capacity of actor's mailbox #293

qwwdfsad opened this issue Mar 20, 2018 · 3 comments

Comments

@qwwdfsad
Copy link
Contributor

qwwdfsad commented Mar 20, 2018

Currently actors have no mailbox by default (capacity = 0) which effectively transforms them to rendezvous. Though ability to have such actors may be useful, this default is unexpected and probably will lead to less efficient/expected behaviour.
As an example, specifying capacity to 1 in PingPongActorBenchmark significantly improves score in every setup (fjp, blocking, single thread executor).

It makes sense to either increase this limit to any reasonable constant or make mailbox unlimited by default (as it's done in Akka). Note that this change may break existing code and/or change its behaviour

@venkatperi
Copy link
Contributor

venkatperi commented Apr 9, 2018

A few thoughts:

  • Making channel capacity unlimited invites memory issues. e.g. channels upstream from a blocking channel may continue to allocate buffers while there is incoming data and eventually run out of memory.
  • A large but bounded number of buffers may be inefficient both in terms of memory and also latency, since data may sit in numerous unneeded queues before being consumed.
  • capacity=1 - is like the ping in a ping-pong scheme. If a producer and consumer, both of which take a small but finite time for completion, share a single buffer, its quite likely their performance will be hobbled.
  • capacity22 - ping/pong scheme isn't ideal for real world cases where it takes a small but finite amount of time to fill a buffer due to potential starvation.
  • capacity=3 - e.g. an video camera where one buffer is filled while a previously filled buffer is processed. ping, pong plus one works better otherwise either of the previous processes may be starved and result in reduce throughput.
  • Generally speaking, the ideal number of buffers depends on the number of simultaneous users and whether the buffers belong to a reusable pool or are send-and-forget. In a reusable pool (to minimize allocations) scheme, the buffer count is ideally the number of agents that can simultaneously hold a buffer + 1 (ish).
  • FWIW: NodeJS uses a default capacity of 16 for object types.

So Four?

@elizarov
Copy link
Contributor

I would not hard-code a default capacity, but, at least, make it configurable via some kind of system property. For me, personally, a default values from 4 to 16 all seem reasonable.

Also, I would not record it separately, but it seems prudent to set actor's default value of start parameter to CoroutineStart.LAZY. See #87

@qwwdfsad qwwdfsad self-assigned this May 23, 2018
@qwwdfsad
Copy link
Contributor Author

Will be fixed in new actors, current ones are going to be deprecated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants