Моей первой мыслью было бы, что Guid
объекты быстрее, но если вы получаете какой-либо ввод в виде строки и вам нужно искать его в небольшом наборе (hashset) идентификаторов GUID (которые меняются не часто), может быть быстрее хранить их как строки, потому что:
Для поиска строки в GUID-словаре необходимо проанализировать строку (включая проверку ошибок и т. Д.), Создать структуру Guid
, получить хэш-код, выполнить поиск хеш-функции и выполнить одно окончательное сравнение. байтов GUID.
Для поиска строки в String-Dictionary вы должны создать хеш строки (возможно, быстрее, чем построение структуры Guid
), найти хэш и выполнить сравнение одной строки. Если, например, вы ожидаете, что многие GUID не будут присутствовать в коллекциях, сравнение хэшей часто будет неудачным, и вам даже не придется выполнять сравнение строк (что занимает немного больше времени, чем сравнение GUID из пункта 1 выше)
Если у вас уже есть структуры Guid в качестве входных данных (например, потому что вы провели некоторую проверку правильности входных строк), конечно, гораздо лучше использовать их в качестве индекса в словаре.
НО : С точки зрения ясности дизайна (что гораздо важнее, чем производительность в 99% всего кода) вы должны использовать Guid
структуры и изменять их только в том случае, если вы действительно столкнетесь с проблемы с производительностью (и профилирование показывает, что вы получаете преимущество от строкового решения).