Что самый эффективный путь состоит в том, чтобы сделать справочную таблицу в C#

Если у вас есть много зарезервированных (в настоящее время неиспользуемых) значений или если диапазон целочисленных значений может стать очень большим, я бы использовал общий словарь (Dictionary):

var myDictionary = new Dictionary<int, string>();
myDictionary.Add(0, "Value 1");
myDictionary.Add(200, "Another value");
// and so on

В противном случае, если у вас есть фиксированное количество значений, и только некоторые из них в настоящее время не используются, тогда я бы использовал массив строк (string [200]) и установил / оставил зарезервированные записи равными нулю.

var myArray = new string[200];
myArray[0] = "Value 1";
myArray[2] = "Another value";
//myArray[1] is null

Самый быстрый способ поиска целочисленных значений в C # - это массив. Это будет предпочтительнее, чем использование словаря, возможно, если вы пытаетесь выполнять десятки тысяч поисков за раз. Для большинства целей это перебор; более вероятно, что вам нужно оптимизировать время разработчика, чем процессорное время.

Если зарезервированные ключи - это не просто все ключи, которых нет в таблице поиска (то есть, если поиск ключа может вернуть найденное значение, не -found status или зарезервированный статус) вам нужно где-то сохранить зарезервированные ключи. Сохранение их как словарных статей с магическими значениями (например, ключ любой словарной статьи, значение которой равно нулю, зарезервирован) можно, если вы не напишете код, который перебирает записи словаря без их фильтрации.

Оформить заказ в HybridDictionary. Он автоматически настраивает свой базовый механизм хранения в зависимости от размера для достижения максимальной эффективности.

http://msdn.microsoft.com/en-us/library/system.collections.specialized.hybriddictionary.aspx

Я бы использовал словарь для поиска. На сегодняшний день это наиболее эффективный способ поиска. Использование строки будет выполняться где-то в области O (n), чтобы найти объект.

Было бы полезно иметь второй Словарь, чтобы все вы могли выполнять обратный поиск, если это необходимо

Я не совсем уверен, что правильно понимаю вашу проблему. У вас есть набор струн. Каждая строка связана с индексом. Потребительские запросы дают индекс, и вы возвращаете соответствующую строку, если индекс не зарезервирован . Верно?

Разве нельзя просто установить в массиве зарезервированные элементы как null.

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

В любом случае, вы, вероятно, получите более точные ответы, если проясните свою проблему.

Встроенный объект Dictionary (предпочтительно универсальный словарь) идеально подходит для этого и специально разработан для быстрого / эффективного поиска значений, относящихся к ключам.

Из ссылки Статья MSDN:

Получение значения по его ключу очень быстро, близко к O (1), потому что Словарь <(Of <(TKey, TValue>)>) class реализован как хэш-таблица.

Что касается ваших «зарезервированных» ключей, я бы вообще не беспокоился об этом, если мы говорим только о нескольких сотнях ключей / значений. Только когда вы достигнете десятков, может быть, сотен тысяч «зарезервированных» ключей / значений, вы захотите реализовать что-то более эффективное.

В таких случаях, вероятно, наиболее эффективным контейнером для хранения будет реализация Разреженная матрица .

Загрузите все свои значения в

var dic = new Dictionary<int, string>();

и используйте это для поиска:

string GetDescription(int val)
{
     if(0 <= val && val < 256)
        if(!dic.Contains(val))
           return "Reserved";
        return dic[val];
    throw new ApplicationException("Value must be between 0 and 255");
}

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

Если ваш ключ запроса является строковым значением, то он больше похож на настоящую таблицу поиска. Использовать объект Dictionary просто, но если вам нужна необработанная скорость для набора из 50 или около того фактических ответов, самостоятельный подход, такой как двоичный поиск или trie, может быть быстрее. Если вы используете бинарный поиск, так как количество элементов очень мало, вы можете развернуть его.

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

С другой стороны, Я предполагаю, что вы доказали, что этот поиск является вашим узким местом, либо профилированием, либо снятием стека . Если на этот запрос тратится менее 10% времени «когда-то медленно», то это не ваше узкое место, поэтому вы также можете делать то, что проще всего кодировать.