feat: Use unbounded channel pattern for mailbox to improve performance

[AlexanderTar]

Inspired by https://github.com/golang-design/chann but using thread-safe buffer underneath

[Tochemey]

I really appreciate the PR. However, I suggest that you add a new mailbox that implements the Mailbox interface.

I am also open if you are suggesting changing the Mailbox interface.

[Tochemey]

Please don't change the Mailbox interface. It is there to allow anyone to implement a custom mailbox. For instance, you can add your custom implementation using this interface.

[Tochemey]

Also, I would like to know whether you are suggesting changing the mailbox interface.
The interface is there to allow a custom mailbox implementation.

[Tochemey]

@AlexanderTar Also, once you complete your new mailbox implementation, I suggest running the benchmark code to see whether there is a performance improvement.

[Tochemey]

Also I suggest not to change the go version

[Tochemey]

@AlexanderTar I run your pr locally to check the performance gain and this is the result:

The same bench mark run on the main branch:

I think there is no much difference comparing the two. I am sure there are places in the code we can improve upon.

[AlexanderTar]

@Tochemey thanks for looking into this so quickly. I admit, I didn't run benchmarks test, so didn't realise the benefits are negligible.

I do, however, suggest we change Mailbox interface slightly by introducing Iterator() method (#188). It does improve benchmark slightly, but the main improvement is that we avoid busy thread in receive() method of pid. When I was experimenting with eGo for my own service, I noticed that spawning projections immediately makes CPU run at 100%, which profiler suggested is due to pid.receive() spinning, by introducing Iterator() as part of Mailbox interface we can now block until message is available instead of pointlessly spin in for waiting for a new message

[Tochemey]

@Tochemey thanks for looking into this so quickly. I admit, I didn't run benchmarks test, so didn't realise the benefits are negligible.

I do, however, suggest we change Mailbox interface slightly by introducing Iterator() method (#188). It does improve benchmark slightly, but the main improvement is that we avoid busy thread in receive() method of pid. When I was experimenting with eGo for my own service, I noticed that spawning projections immediately makes CPU run at 100%, which profiler suggested is due to pid.receive() spinning, by introducing Iterator() as part of Mailbox interface we can now block until message is available instead of pointlessly spin in for waiting for a new message

Thanks for this observation. That makes sense. I will take a look at the PR.

[Tochemey]

@AlexanderTar I merged the other PR. I am going to close this PR. Feel free to bring out any suggestion that will enhance performance 😉