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 stage runs quite a bit faster than `Source.actorRef`:
https://github.com/timcharper/as-actorref-repro/tree/ingestor-benchmark `Source.queue` is probably fine enough, but in reality, there's no reason it should perform worse than `Source.actorRef`. It could be sped up significantly while retaining the same functionality by following the same pattern of using the atomicBoolean to reduce scheduling callbacks. Two internal queues could be used, one queue a java.util.concurrent.ConcurrentLinkedQueue, the other queue a mutable, non-thread-safe queue. On each run of the stage callback, the OverflowStrategy could be applied quite safely. Since the java.util.concurrent.ConcurrentLinkedQueue will be only pushed to from async threads, a current total + the current size of the non-thread-safe mutable queue could be calculated to see if overflow had occurred, and then the strategy applied accordingly. Just wanted to post these thoughts somewhere while they were on my mind. I don't know if the optimization would be worth pursuing, just that a 2-3x improvement in speed for Source.queue should be possible. Tim -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
