Который быстрее/больше эффективен: Словарь <строка, объект> или Словарь <перечисление, объект>?
Если ваша исходная папка является обычной папкой Windows (которая обновляется потоком файлов Google, а не папкой файлового потока Google), вы можете использовать класс FileSystemWatcher. Этот класс просматривает папку для указанных изменений и вызывает события, когда они происходят (которые ваше приложение может затем обработать).
Вот статья, которую я использовал, когда мне нужно было сделать нечто подобное (просмотр папки на предмет изменений). Как работать с наблюдателем файловой системы в C #
. Вот краткое изложение, извлеченное непосредственно из него:
Следующий фрагмент кода показывает, как должен выглядеть метод MonitorDirectory. Этот метод будет использоваться для мониторинга определенного каталога и генерирования событий при каждом изменении. Путь к каталогу передается методу в качестве аргумента.
blockquote>private static void MonitorDirectory(string path) { FileSystemWatcher fileSystemWatcher = new FileSystemWatcher(); fileSystemWatcher.Path = path; fileSystemWatcher.Created += FileSystemWatcher_Created; fileSystemWatcher.Renamed += FileSystemWatcher_Renamed; fileSystemWatcher.Deleted += FileSystemWatcher_Deleted; fileSystemWatcher.EnableRaisingEvents = true; }Вы можете заменить свои собственные обработчики событий (или реализовать их с именами выше).
Для получения дополнительного бонуса вы также можете использовать свойство фильтра FileSystemWatcher для нацеливания на определенные типы файлов.
Полная документация по Microsoft Docs
5 ответов
Конечно, версия enum лучше (когда оба применимы и имеют смысл, конечно). Не только для производительности (может быть лучше или хуже, см. Очень хороший комментарий Рашака) , поскольку он проверяет время компиляции и приводит к более чистому коду.
Я думаю, вам следует начать с концентрации на правильности. Это гораздо важнее, чем минимальная разница между незначительными различиями в производительности, которые могут возникнуть в вашей программе. В этом случае я бы сфокусировался на правильном представлении ваших типов (enum кажется лучшим). Затем, позже, профилируйте ваше приложение и, если есть проблема, тогда и только тогда вы должны ее исправить.
Создание более быстрого кода на более поздних этапах процесса обычно является простым процессом. Возьми ссылку, которую предоставила сколима. Если бы вы выбрали enum, было бы приблизительно 10-минутное исправление, чтобы устранить потенциальную потенциальную проблему производительности в вашем приложении. Я хочу подчеркнуть слово потенциал здесь. Это определенно было проблемой для NHibernate, но вопрос о том, будет ли это проблемой для вашей программы, будет зависеть только от ее использования.
С другой стороны, сделать код более корректным позже в этом процессе, как правило, более сложно. В достаточно большой проблеме вы обнаружите, что люди начинают зависеть от побочных эффектов предыдущего плохого поведения. Это может сделать исправление кода без проблем с другими компонентами.
Это может сделать исправление кода без проблем с другими компонентами. Это может сделать исправление кода без проблем с другими компонентами.Используйте enum, чтобы получить более чистый и приятный код, но не забудьте предоставить пользовательский компаратор, если вас беспокоит производительность : http://ayende.com/Blog/archive/2009/02/21/dictionaryltenumtgt-puzzler.aspx .
Может не применяться, но ...
Имейте в виду, что перечисления скомпилированы как константы , что может вызвать перераспределение всех сборок, которые ссылаются на enum, если он изменен. (то есть константа жестко закодирована во время компиляции для всех сборок, которые ее используют).
Я думаю, что версия enum быстрее. Под капотом словарь ссылается на все по хеш-коду. Я предполагаю, что медленнее генерировать хеш-код для строки. Тем не менее, это, вероятно, значительно медленнее, и, скорее всего, быстрее, чем что-либо вроде сравнения строк. Я согласен с другими авторами, которые сказали, что перечисление чище.