Hi Tim,
Feel free to experiment with these, I think these can be a good improvement
for Source.queue. Source.actorRef is somewhat different though, it does not
use a real ActorRef, it is a very special construct that makes a GraphStage
look like an actor from the outside, but in fact all messages
Well, to counter this argument, I think this is a question that should be
asked of Source.queue and Source.actorRef, also. Source.actorRef will
buffer forever with its mailbox, and the overflow protection is applied as
that mailbox is drained, when the Actor is gets an opportunity to run.
What happens if the queue is flooded before overflow protection kicks in?
On Mon, May 9, 2016 at 10:19 AM, Tim Harper wrote:
> You're right. However, we could leverage the fact that the queue size only
> grows outside of the stage process. So, I think we could use a
You're right. However, we could leverage the fact that the queue size only
grows outside of the stage process. So, I think we could use a counter.
> On May 9, 2016, at 01:29, Viktor Klang wrote:
>
> Isn't CLQ.size O(N)?
>
> --
> Cheers,
> √
>
> On May 9, 2016 7:38
Isn't CLQ.size O(N)?
--
Cheers,
√
On May 9, 2016 7:38 AM, "Tim Harper" wrote:
> I did some benchmarking to see how well `Source.actorRef` and
> `Source.queue` performed. Also, I wanted to see how much better I could do
> if I didn't need my Source to buffer (this stream
I did some benchmarking to see how well `Source.actorRef` and
`Source.queue` performed. Also, I wanted to see how much better I could do
if I didn't need my Source to buffer (this stream is using conflate). It
turns out, `Source.queue` is slower than `Source.actorRef`. And, the custom
graph