TryGetValue и ContainsKey должны быть довольно быстрыми при таком размере, если ключ имеет хорошо распределенные хэши.
Словарь имеет индексируемое количество «сегментов».Когда он добавляет или ищет значение по ключу, он принимает значение, возвращаемое GetHashCode (), снова хэширует его, чтобы оно было меньше количества сегментов (обычно что-то простое, например, по модулю, но реализация не определена),и посмотрите в соответствующее ведро.
В настоящее время ведро будет иметь ноль или более предметов.Словарь сравнивает каждый элемент с ключом, используя .Equals ().
Первый бит поиска правильного сегмента будет в постоянном времени O (1).Второй бит сравнения ключа с ключами в корзине будет происходить за линейное время O (n), где n относится только к количеству элементов в этой корзине, а не во всей коллекции.
Обычнов каждом сегменте должно быть очень мало элементов (количество сегментов будет расти, чтобы попытаться сохранить это положение), поэтому операция по существу постоянна.
Если, однако, ваши хэш-коды плохо реализованы, будетмного ключей в одном ведре.Временная сложность будет становиться все ближе и ближе к O (n), что можно увидеть, экспериментируя с объектом с намеренно плохим GetHashCode, который просто возвращает 0 каждый раз.В худшем случае он хуже, чем List, поскольку List также является O (n), но у Dictionary есть дополнительные накладные расходы.
Значит ли это, что вам следует беспокоиться?Нет, даже относительно наивные методы хеширования должны давать относительно хорошие результаты.Если вы используете строковый ключ, то он, вероятно, будет более чем достаточно хорош.Если вы используете простой встроенный тип, то тем более.
Если вы обнаружите, что доступ к словарю медленный, то вы должны обратить на это внимание и либо исправить GetHashCode ()или создайте IEqualityComparer (который позволяет определять внешние правила для GetHashCode () и Equals () для использования со словарями, хэш-наборами и т. д.).
Скорее всего, 3000 - ничто, все будет хорошо.