recently I was working on the Reactive Queue (which is part of the Rx Contrib).
the requirement for the Reactive Queue was to to achieve the highest throughput possible
for each queue provider (2,000,000 messages of 500 byte per second using Concurrent Queue provider
running on simple quad server).
while working on this project I was encounter the the following performance hits:
there is a big difference between using the old ManualResetEvent Vs. ManualResetEventSlim the hit
factor can go up to 2 or 3 times slower if you having a very short synchronization period
(the ManualResetEventSlim does not escalate to kernel mode on short period waiting).
do not expose the ManualResetEventSlim instance using the WaitHandle, as shown in the following code snippet:
consuming ManualResetEventSlim though its WaitHandle property does not gain
performance improvements benefits.
if you do want to expose synchronization API, use the following code:
when ever using CancellationToken:
do monitor GC collect counter, especially the 3rd generation collection.
trying to use this technique I got a huge hit (3.5 times slower), because of
extra (multiple) GC 3rd generation collection.
instead of using the CancellationToken the Reactive Queue is using old good
do consider to use Thread.Yield().
putting it on the right places may improve overall performance,
but you have to be careful and measure the actual performance, because
doing it on the wrong places may result as performance hit.
performance improving required continuously measurement which should
be compared with historical measurement.
be careful with synchronization and do use the new .net synchronization types like ManualResetEventSlim.