title: BlockingCollection(T) performance
body: <p>For a while at my company we've used a home-grown <code>ObjectPool&lt;T&gt;</code> implementation that provides blocking access to its contents. It's pretty straightforward: a <code>Queue&lt;T&gt;</code>, an <code>object</code> to lock on, and an <code>AutoResetEvent</code> to signal to a "borrowing" thread when an item is added.</p>
  
  <p>The meat of the class is really these two methods:</p>
  
  <pre><code>public T Borrow() {
      lock (_queueLock) {
          if (_queue.Count &gt; 0)
              return _queue.Dequeue();
      }
  
      _objectAvailableEvent.WaitOne();
  
      return Borrow();
  }
  
  public void Return(T obj) {
      lock (_queueLock) {
          _queue.Enqueue(obj);
      }
  
      _objectAvailableEvent.Set();
  }
  </code></pre>
  
  <p>We have been using this and a few other collection classes instead of those provided by <code>System.Collections.Concurrent</code> because we are using .NET 3.5, not 4.0. But recently we discovered that since we are using <a href="http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx" rel="noreferrer">Reactive Extensions</a>, we actually <em>do</em> have the <code>Concurrent</code> namespace available to us (in System.Threading.dll).</p>
  
  <p>Naturally, I figured that since <a href="http://msdn.microsoft.com/en-us/library/dd267312.aspx" rel="noreferrer"><code>BlockingCollection&lt;T&gt;</code></a> is one of the core classes in the <code>Concurrent</code> namespace, it would probably offer better performance than anything I or my teammates wrote.</p>
  
  <p>So I tried writing a new implementation that works very simply:</p>
  
  <pre><code>public T Borrow() {
      return _blockingCollection.Take();
  }
  
  public void Return(T obj) {
      _blockingCollection.Add(obj);
  }
  </code></pre>
  
  <p>To my surprise, according to some simple tests (borrowing/returning to the pool a few thousand times from multiple threads), our original implementation <strong>significantly beats <code>BlockingCollection&lt;T&gt;</code> in terms of performance</strong>. They both appear to work <em>correctly</em>; it's just that our original implementation seems to be much faster.</p>
  
  <p>My question:</p>
  
  <ol>
  <li>Why would this be? Is it perhaps because <code>BlockingCollection&lt;T&gt;</code> offers greater flexibility (I understand it works by wrapping an <a href="http://IProducerConsumerCollection&lt;T" rel="noreferrer"><code>IProducerConsumerCollection&lt;T&gt;</code></a>), which necessarily introduces performance overhead?</li>
  <li>Is this just a flat-out misguided use of the <code>BlockingCollection&lt;T&gt;</code> class?</li>
  <li>If this is an appropriate use of <code>BlockingCollection&lt;T&gt;</code>, am I just not using properly? For example, is the <code>Take</code>/<code>Add</code> approach overly simplistic, and there's a far better-performing way to get the same functionality?</li>
  </ol>
  
  <p>Unless anyone has some insight to offer in response to that third question, it looks like we'll be sticking with our original implementation for now.</p>