Словарь с двумя хэш-функциями в С#?

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

Рассматривали ли вы использование чего-то более уникального для каждой записи?

Я предполагаю, что каждая запись представляет собой информацию о каталоге файловой системы. Рассматривали ли вы возможность использования ее полного пути в качестве ключа? префикс с именем компьютера / IP-адресом?

С другой стороны, если вы используете количество файлов в качестве хэш-ключа, эти каталоги никогда не изменятся? Потому что, если хеш-ключ/результат изменится, вы никогда не сможете найти его снова.

В этой теме, если содержимое/размер каталога никогда не изменится, можете ли вы сохранить это значение где-нибудь, чтобы сэкономить время, чтобы фактически вычислить это?

Просто мои несколько центов.

В вашем случае вы технически используете модифицированную функцию (A | B), а не двойное хеширование. Однако, в зависимости от того, насколько огромен ваш «огромный» список записей и характеристик ваших данных, рассмотрите следующее:

• Хеш-таблица, заполненная на 20%, с не очень хорошим распределением может иметь вероятность коллизии более 80%. Это означает, что ожидаемая стоимость функции может быть: (0,8 дорого + 0,2 дешево) + (стоимость поиска). Поэтому, если ваша таблица заполнена более чем на 20%, возможно, не стоит использовать схему (A|B).

• Придумать идеальную хеш-функцию можно, но O(n^3), что делает ее непрактичной.

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

Вы ознакомились с Power Collections или C5 Collections библиотеки? В библиотеке Power Collections в последнее время не было особых действий, но материал C5, похоже, довольно актуален.

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

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

Будет ли на самом деле значительное количество объектов, которые будут обнаружены с помощью механизма быстрого хеширования, без необходимости прибегать к более дорогим методам для дальнейшего сужения? Потому что, если вы не можете найти значительную сумму только при первом расчете, вы действительно ничего не сэкономите, сделав это в два этапа (не зная данных, трудно предсказать, так ли это).

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

Редактировать

Я только что видел вашу поправку к вопросу - вы планируете выполнять оба поиска независимо... Я сомневаюсь, что вы получите от этого какие-либо преимущества в производительности, которых вы не можете получить, просто немного лучше настроив основную хеш-таблицу. Вы пытались использовать один словарь с соответствующей емкостью, переданной в конструкторе, и, возможно, XOR двух хэш-кодов в качестве вашего хэш-кода?