BlockingCollection(T)性能

时间:2010-06-14 18:14:32

标签: .net collections thread-safety blocking objectpool

在我公司工作了一段时间,我们使用了一个自行开发的ObjectPool<T>实现,它提供了对其内容的阻止访问。它非常简单:Queue<T>object可以锁定,AutoResetEvent在添加项目时向“借用”线程发出信号。

班上的人真的是这两种方法:

public T Borrow() {
    lock (_queueLock) {
        if (_queue.Count > 0)
            return _queue.Dequeue();
    }

    _objectAvailableEvent.WaitOne();

    return Borrow();
}

public void Return(T obj) {
    lock (_queueLock) {
        _queue.Enqueue(obj);
    }

    _objectAvailableEvent.Set();
}

我们一直在使用这个和其他一些集合类而不是System.Collections.Concurrent提供的集合类,因为我们使用的是.NET 3.5,而不是4.0。但最近我们发现,由于我们使用Reactive Extensions,我们实际上可以使用Concurrent命名空间(在System.Threading.dll中)。

当然,我认为由于BlockingCollection<T>Concurrent命名空间中的核心类之一,因此它可能提供比我或我的队友写的更好的性能。

所以我尝试编写一个非常简单的新实现:

public T Borrow() {
    return _blockingCollection.Take();
}

public void Return(T obj) {
    _blockingCollection.Add(obj);
}

令我惊讶的是,根据一些简单的测试(从多个线程借用/返回池几千次),我们的原始实现在性能方面显着优于BlockingCollection<T> 。它们似乎都正常 ;只是我们原来的实现似乎要快得多。

我的问题:

  1. 为什么会这样?是不是因为BlockingCollection<T>提供了更大的灵活性(我理解它包装了IProducerConsumerCollection<T>),这必然会带来性能开销?
  2. 这只是对BlockingCollection<T>类的错误使用吗?
  3. 如果这是BlockingCollection<T>的恰当用途,我是不是正确使用了?例如,Take / Add方法是否过于简单化,并且有更好的方法来获得相同的功能?
  4. 除非有人在回答第三个问题时提供某些见解,否则我们现在似乎会坚持原来的实施。

3 个答案:

答案 0 :(得分:26)

这里有几种可能的可能性。

首先,Reactive Extensions中的BlockingCollection<T>是一个backport,与.NET 4最终版本不完全相同。如果这个backport的性能不同于.NET 4 RTM,我不会感到惊讶(虽然我没有特别描述这个集合)。大多数TPL在.NET 4中的表现都比在.NET 3.5后端表现更好。

话虽这么说,如果您有一个生产者线程和一个消费者线程,我怀疑您的实现将超出BlockingCollection<T>。对于一个生产者和一个消费者,您的锁对总体性能的影响较小,重置事件是在消费者方面等待的一种非常有效的方法。

但是,BlockingCollection<T>旨在允许许多生产者线程非常好地“排队”数据。这对于您的实现来说效果不佳,因为锁定争用将很快变得有问题。

话虽如此,我还想指出一个误解:

  

......它可能提供比我或我的队友写的更好的表现。

这通常不是真的。框架集合类通常执行非常好,但通常不是给定方案的最高性能选项。话虽如此,他们往往表现良好,同时非常灵活和非常强大。它们通常倾向于非常好地扩展。 “家庭编写的”集合类通常在特定场景中优于框架集合,但在用于特定场景之外的场景中时往往会出现问题。我怀疑这是其中一种情况。

答案 1 :(得分:11)

我在.Net 4中尝试BlockingCollection针对ConurrentQueue/AutoResetEvent组合(类似于OP&#39}的解决方案,但无锁定),后者的组合所以多我的用例更快,我抛弃了BlockingCollection。不幸的是,差不多一年前,我无法找到基准测试结果。

使用单独的AutoResetEvent并不会使事情变得更加复杂。事实上,人们甚至可以一劳永逸地将它抽象为BlockingCollectionSlim ....

BlockingCollection在内部也依赖于ConcurrentQueue,但是does还有一些额外的工作与超薄信号量取消令牌,这产生了额外的功能,但在成本,即使不使用。还应该注意的是,BlockingCollection不与ConcurrentQueue结合,但也可以与IProducerConsumerCollection的其他实现者一起使用。


BlockingCollectionSlim实现无限,相当简单:

class BlockingCollectionSlim<T>
{
    private readonly ConcurrentQueue<T> _queue = new ConcurrentQueue<T>();
    private readonly AutoResetEvent _autoResetEvent = new AutoResetEvent(false);
    public void Add(T item)
    {
        _queue.Enqueue(item);
        _autoResetEvent.Set();
    }
    public bool TryPeek(out T result)
    {
        return _queue.TryPeek(out result);
    }
    public T Take()
    {
        T item;
        while (!_queue.TryDequeue(out item))
            _autoResetEvent.WaitOne();
        return item;
    }
    public bool TryTake(out T item, TimeSpan patience)
    {
        if (_queue.TryDequeue(out item))
            return true;
        var stopwatch = Stopwatch.StartNew();
        while (stopwatch.Elapsed < patience)
        {
            if (_queue.TryDequeue(out item))
                return true;
            var patienceLeft = (patience - stopwatch.Elapsed);
            if (patienceLeft <= TimeSpan.Zero)
                break;
            else if (patienceLeft < MinWait)
            // otherwise the while loop will degenerate into a busy loop,
            // for the last millisecond before patience runs out
                patienceLeft = MinWait;
            _autoResetEvent.WaitOne(patienceLeft);
        }
        return false;
    }
    private static readonly TimeSpan MinWait = TimeSpan.FromMilliseconds(1);

答案 2 :(得分:1)

我在.Net 4.7.2中遇到了BlockingCollection的相同性能问题,并找到了这篇文章。我的情况是MultipleProducers-MultipleConsumers,尤其是从许多来源读取的小数据块,应该由许多过滤器进行处理。使用了几个(Env.ProcessorCount)BlockingCollections,最后我得到了一个性能分析器,告诉我BlockingCollection.GetConsumingEnumerable.MoveNext()比实际过滤消耗更多的CPU时间!

感谢@Eugene Beresovsky的代码。仅供参考:在我的环境中,速度几乎比BlockingCollection慢两倍。所以,这是我的SpinLocked BlockingCollection:

public class BlockingCollectionSpin<T>
{
    private SpinLock _lock = new SpinLock(false);
    private Queue<T> _queue = new Queue<T>();

    public void Add(T item)
    {
        bool gotLock = false;
        try
        {
            _lock.Enter(ref gotLock);
            _queue.Enqueue(item);
        }
        finally
        {
            if (gotLock) _lock.Exit(false);
        }
    }

    public bool TryPeek(out T result)
    {
        bool gotLock = false;
        try
        {
            _lock.Enter(ref gotLock);
            if (_queue.Count > 0)
            {
                result = _queue.Peek();
                return true;
            }
            else
            {
                result = default(T);
                return false;
            }
        }
        finally
        {
            if (gotLock) _lock.Exit(false);
        }
    }

    public T Take()
    {
        var spin = new SpinWait();
        do
        {
            bool gotLock = false;
            try
            {
                _lock.Enter(ref gotLock);
                if (_queue.Count > 0)
                    return _queue.Dequeue();
            }
            finally
            {
                if (gotLock) _lock.Exit(false);
            }
            spin.SpinOnce();
        } while (true);
    }
}

对于性能至关重要的代码,我建议避免使用readonly字段修饰符。它添加了对IL中每个字段访问的检查。使用以下测试代码

private static void TestBlockingCollections()
{
    const int workAmount = 10000000;
    var workerCount = Environment.ProcessorCount * 2;
    var sw = new Stopwatch();
    var source = new long[workAmount];
    var rnd = new Random();
    for (int i = 0; i < workAmount; i++)
        source[i] = rnd.Next(1000000);

    var swOverhead = 0.0;
    for (int i = 0; i < workAmount; i++)
    {
        sw.Restart();
        swOverhead += sw.Elapsed.TotalMilliseconds;
    }
    swOverhead /= workAmount;

    var sum1 = new long[workerCount];
    var queue1 = new BlockingCollection<long>(10000);
    var workers = Enumerable.Range(0, workerCount - 1).Select(n =>
    Task.Factory.StartNew(() =>
    {
        foreach (var l in queue1.GetConsumingEnumerable())
            sum1[n] += l;
    })).ToArray();

    Thread.Sleep(1000);

    sw.Restart();
    foreach (var l in source)
        queue1.Add(l);
    queue1.CompleteAdding();
    Task.WaitAll(workers);
    var elapsed = sw.Elapsed.TotalMilliseconds - swOverhead;
    Console.WriteLine("BlockingCollection {0:F4}ms", elapsed / workAmount);

    var sum2 = new long[workerCount];
    var queue2 = new BlockingCollectionSlim<long?>();
    workers = Enumerable.Range(0, workerCount - 1).Select(n =>
    Task.Factory.StartNew(() =>
    {
        long? l;
        while ((l = queue2.Take()).HasValue)
            sum2[n] += l.Value;
    })).ToArray();

    Thread.Sleep(1000);

    sw.Restart();
    foreach (var l in source)
        queue2.Add(l);
    for (int i = 0; i < workerCount; i++)
        queue2.Add(null);
    Task.WaitAll(workers);
    elapsed = sw.Elapsed.TotalMilliseconds - swOverhead;
    Console.WriteLine("BlockingCollectionSlim {0:F4}ms", elapsed / workAmount);

    var sum3 = new long[workerCount];
    var queue3 = new BlockingCollectionSpin<long?>();
    workers = Enumerable.Range(0, workerCount - 1).Select(n =>
    Task.Factory.StartNew(() =>
    {
        long? l;
        while ((l = queue3.Take()).HasValue)
            sum3[n] += l.Value;
    })).ToArray();

    Thread.Sleep(1000);

    sw.Restart();
    foreach (var l in source)
        queue3.Add(l);
    for (int i = 0; i < workerCount; i++)
        queue3.Add(null);
    Task.WaitAll(workers);
    elapsed = sw.Elapsed.TotalMilliseconds - swOverhead;
    Console.WriteLine("BlockingCollectionSpin {0:F4}ms", elapsed/workAmount);

    if (sum1.Sum() != sum2.Sum() || sum2.Sum() != sum3.Sum())
        Console.WriteLine("Wrong sum in the end!");

    Console.ReadLine();
}

在具有2个内核并启用HT的Core i5-3210M上,我得到以下输出:

BlockingCollection     0.0006ms
BlockingCollectionSlim 0.0010ms (Eugene Beresovsky implementation)
BlockingCollectionSpin 0.0003ms

因此,SpinLocked版本比.Net BlockingCollection快两倍。但是,我建议只使用它!如果您真的更喜欢性能而不是代码的简单性(和可维护性)。