Почему у ConcurrentQueue нет capacity, как его неконкурентный кузен? Также не упоминается емкость по умолчанию.Почему нет емкости в ConcurrentQueue?
Имеет ли «недостающая» мощность влияние на производительность по сравнению с неконкурентной версией, где разработчик может предоставить квалифицированную оценку типичного размера очереди?
ConcurrentQueue реализуется с использованием технологий блокировки. Он основан на «Связанном списке». Емкость не имеет смысла в Связанном списке, поэтому она не раскрывает емкость.
Добавление элементов в LinkedList является дешевым, оно не требует изменения размера массива. Он просто модифицирует указатель хвоста (ссылка). Если реализация использует массив, то изменение размера массива будет дорогостоящим, поэтому предварительное распределение массива значительно улучшит производительность, когда вы ставите в очередь много элементов.
Другие неконкурентные реализации Queue (System.Collections.Generic.Queue<T> и System.Collections.Queue) основаны на массиве. Поэтому имеет смысл предварительно выделить массив с заданной емкостью, чтобы избежать частого изменения размера массива и, таким образом, он предоставляет свойство Capacity.
@Downvoter Объяснение, что не так с ответом, будет оценено по достоинству. –
Я действительно ненавижу случайных @downvoters. Скажи это, если что-то не так. Не нажимайте и не бегите. –
Действительно. Мы взрослые. Мы не будем проголосовать за нас, чтобы проголосовать за нас ... @ downvoters –
Поскольку для реализации не требуется емкость? Параллельные и неконкурентные структуры данных имеют разные реализации. – TcKs
Возможно, вы проверите [этот пост] (http://www.codethinked.com/net-40-and-system_collections_concurrent_concurrentqueue) - способ, которым он реализован, полностью отличается от неконкурентного, который имеет только один внутренний массив. Таким образом, рассказывая, сколько элементов вы собираетесь добавить первым, а затем добавляете их или не даете эту информацию и просто добавляете элементы, вы получите точно такое же количество распределений. –