Управление памятью словаря C#
Мое решение состоит в том, чтобы создать отображение UserName в dict в списке user_id:
users = [[u'ken'], [u'ted']]
user_id = [
{u'UserName': u'ted', u'LastSeen': u'x'},
{u'UserName': u'ken', u'LastSeen': u'x'}
]
seen_map = {u['UserName']: u for u in user_id}
user_details = []
for u in users:
try:
user_details.append(seen_map[u[0]])
except KeyError:
user_details.append('{0} not found in list'.format(u[0]))
print user_details
# for users = [[u'ken'], [u'ted']]
# [{u'UserName': u'ken', u'LastSeen': u'x'}, {u'UserName': u'ted', u'LastSeen': u'x'}]
# for users = [[u'barby'], [u'ted']]
# ['barby not found in list', {u'UserName': u'ted', u'LastSeen': u'x'}]
Таким образом, вам нужно только один раз просмотреть список user_id создать отображение, не один раз для каждого элемента в users.
6 ответов
Таким образом, я недавно сделал что-то подобное и для определенного набора причин, которые довольно уникальны для моего приложения, не использовал базу данных. На самом деле я был попыткой прекратить использовать базу данных. Я нашел, что GetHashCode значительно улучшен в 3,5. Одно важное примечание, НИКОГДА НЕ ХРАНИТЕ ПОСТОЯННО РЕЗУЛЬТАТЫ GetHashCode. НИКОГДА. Они, как гарантируют, не будут последовательны между версиями платформы.
Таким образом, действительно необходимо провести анализ данных, так как различные хеш-функции могли бы работать лучше или хуже на данных. Также необходимо объяснить скорость. Как правило криптографические хеш-функции не должны иметь многих коллизий, как раз когда количество хешей перемещается в миллиарды. Для вещей, что я должен быть уникальным, я обычно использую Управляемый SHA1. В целом CryptoAPI имеет ужасную производительность, даже если базовые хеш-функции работают хорошо.
Для хеша на 64 бита я в настоящее время использую Lookup3 и FNV1, которые являются оба хешами на 32 бита, вместе. Чтобы коллизия произошла и должна была бы столкнуться, который является математически невероятным, и я не видел, происходят приблизительно по 100 миллионам хешей. Можно найти код обоим общедоступным в сети.
Все еще проведите свой собственный анализ. То, что работало на меня, не может работать на Вас. На самом деле в моем офисе различные приложения с различными требованиями на самом деле используют различные хеш-функции или комбинации хеш-функций.
Я избежал бы любых бездоказательных хеш-функций. Существует столько же хеш-функций сколько люди, которые думают, что должны писать им. Проведите свое исследование и протестируйте тестовый тест.
С 10 миллионами нечетных записей Вы рассмотрели использование базы данных с некластерным индексом? Базы данных имеют намного больше приемов их рукав для этого типа вещи.
Хеширование, по определению, и в соответствии с любым алгоритмом, имеет потенциал коллизий - особенно с большими объемами. В зависимости от сценария я был бы очень осторожен из этого.
Используя строки мог бы занять место, но это надежно..., если Вы находитесь на x64, это не должно быть слишком большим (хотя это определенно рассчитывает как "большое";-p)
Почему Вы просто не используете GetHashCode() получить хеш строки?
Просто пойдите, получают SQLite. Вы вряд ли победите его, и даже если Вы сделаете, то это, вероятно, не будет стоить времени/усилия/сложности.
SQLite.
С реализациями хеш-таблицы я работал с в прошлом хешем, приносит Вам к блоку, который часто является списком ссылок других объектов, которые имеют тот же хеш. Хеши не уникальны, но они достаточно хороши для разделения данных на очень управляемые списки (иногда только 2 или 3 длинных), что можно затем искать, хотя найти фактический объект.
Ключ к хорошему хешу не является своей уникальностью, но своей скоростью и возможностями распределения... Вы хотите, чтобы он распределил максимально равномерно.
Между прочим, криптографические хеши / хеш-функции исключительно плохи для словарей. Они являются большими и медленными. Путем решения одной проблемы (размер) Вы только представили другого, более серьезную проблему: функция не распространит вход равномерно больше, таким образом уничтожая единственное самое важное свойство хорошего хеша для приближения к обращению без коллизий (поскольку Вы, кажется, заметили себя).
/ РЕДАКТИРОВАНИЕ: Поскольку Andrew отметил, GetHashCode решение для этой проблемы, так как это - ее надлежащее использование. И как в истинном словаре, необходимо будет работать вокруг коллизий. Одна из лучших схем этого удваивает хеширование. К сожалению, только 100%-й надежный путь будет состоять в том, чтобы на самом деле сохранить исходные значения. Еще, Вы создали бы бесконечное сжатие, которое мы знаем, не может существовать.