BlockingCollection (T) производительность

Некоторое время в моей компании мы использовали собственной разработки ObjectPool реализация, которая обеспечивает блокирующий доступ к его содержанию. Это довольно просто: a Queue, 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. Но недавно мы обнаружили, что, так как мы используем Реактивные Расширения, мы на самом деле имеем Concurrent пространство имен, доступное нам (в System.Threading.dll).

Естественно, я полагал это с тех пор BlockingCollection один из базовых классов в Concurrent пространство имен, это, вероятно, предложило бы лучшую производительность, чем что-нибудь, что я или мои товарищи по команде записали.

Таким образом, я пытался писать новую реализацию, которая работает очень просто:

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

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

К моему удивлению, согласно некоторым простым тестам (одалживающий/возвращающий к пулу несколько тысяч раз от нескольких потоков), наша исходная реализация значительно бьется BlockingCollection с точки зрения производительности. Они оба, кажется, работают правильно; это просто, что наша исходная реализация, кажется, намного быстрее.

Мой вопрос:

1. Почему это было бы? Это, возможно, потому что BlockingCollection предлагает большую гибкость (я понимаю, что она работает путем обертывания IProducerConsumerCollection), который обязательно представляет производительность наверху?
2. Это просто утончение дезинформированного использования BlockingCollection класс?
3. Если это - соответствующее использование BlockingCollection, разве я просто не использую правильно? Например, Take/Add чрезмерно упрощенный подход, и существует далекий лучше работающий способ получить ту же функциональность?

Если у любого нет некоторого понимания для предложения в ответ на тот третий вопрос, похоже, что мы будем придерживаться нашей исходной реализации на данный момент.