CODEWITHSUNDEEP
c#
Oleg Vazhnev
Oleg Vazhnev

Reputation: 24067

performance of ConcurrentQueue vs Queue + lock

I have to implement one-consumer one-producer standard algorithm. I can implement it using Queue and couple of lock statements easily. Or I can just use ConcurrentQueue. What is better?

If Queue + lock is used then I can optimize "multiple addition/retreival", because I can lock once and then Add many times.

What is faster in general case - ConcurrentQueue or Queue + lock and how much the difference is? Of course ConcurrentQueue is the most straigt forward way but I do not want to loose a lot of performance as I'm using this in HFT trading application.

Upvotes: 26

Views: 19129

Answers (2)

Mohsen Hosseinalizadeh
Mohsen Hosseinalizadeh

Reputation: 315

Additionally, from Microsoft documentation regarding ConcurrentQueue(T) vs. Queue(T):

In pure producer-consumer scenarios, where the processing time for each element is very small (a few instructions), then System.Collections.Concurrent.ConcurrentQueue can offer modest performance benefits over a System.Collections.Generic.Queue that has an external lock. In this scenario, ConcurrentQueue performs best when one dedicated thread is queuing and one dedicated thread is de-queuing. If you do not enforce this rule, then Queue might even perform slightly faster than ConcurrentQueue on computers that have multiple cores.

When processing time is around 500 FLOPS (floating point operations) or more, then the two-thread rule does not apply to ConcurrentQueue, which then has very good scalability. Queue does not scale well in this scenario.

In mixed producer-consumer scenarios, when the processing time is very small, a Queue that has an external lock scales better than ConcurrentQueue does. However, when processing time is around 500 FLOPS or more, then the ConcurrentQueue scales better.

Upvotes: 2

Rotem
Rotem

Reputation: 21927

From C# in a Nutshell:

The concurrent stack, queue, and bag classes are implemented internally with linked lists. This makes them less memory efficient than the nonconcurrent Stack and Queue classes, but better for concurrent access because linked lists are conductive to lock-free or low-lock implementations.

In other words, it's hard to define a general case, not to mention predict what the difference in performance will be.

It depends on the size of the collection and the usage. Performance can be expected to be better given enough concurrent access, memory consumption will be worse.

Upvotes: 30

Related Questions