3

Simple question, complex problem:

A LOT of data coming in from the network on a single socket, faster than one thread can consume. In fact, even dispatching the work to the ThreadPool takes too much time.

So I add the incoming items to a BlockingCollection<T> and then dispatch them on a separate thread.

However, at times of high usage, it can still take too long. I tried stripping the BlockingCollection<T> and ConcurrentQueue<T> implementations to remove some extraneous features but it made little difference.

What kind of single-write multi-read concurrent queue implementation could beat the BlockingCollection<T>? The data must be consumed ASAP.

georgiosd
  • 3,038
  • 3
  • 39
  • 51
  • 1
    Try gathering N elements into a simple `List`, then when it is full (or the data stops coming), enqueue the entire list as 1 workload into the threadpool or a similar construct, then start a new list. – Lasse V. Karlsen Jul 21 '15 at 19:41
  • I guess I should add as a requirement that consuming the stream as fast as possible is very important. – georgiosd Jul 21 '15 at 20:09
  • Yes, but batching up a few elements for one workload should reduce the overhead of queueing it. If you get so many elements that you're having problems dispatching it, you need to reduce the overhead of dispatching it, and it doesn't sound like you would process them any faster by dispatching them one at a time anyway, if you get that many that fast. – Lasse V. Karlsen Jul 21 '15 at 20:10
  • 1
    There really isn't anything faster. Jon Skeet sums it up pretty well: http://stackoverflow.com/questions/5001003/fast-and-best-producer-consumer-queue-technique-blockingcollection-vs-concurrent – Adam Jul 21 '15 at 20:14
  • Lasse's solution is good, but make sure to initialize the capacity of the list when you create it, to avoid later allocations and copies when the size must be increased. – Thomas Levesque Jul 21 '15 at 20:19
  • What about a circular-array queue? Wouldn't that be an improvement? – georgiosd Jul 22 '15 at 05:45

0 Answers0