№ блокировки. Медленно, зависит от того, с чем вы его сравниваете. Это довольно дешево с точки зрения ввода-вывода, но ввод-вывод обычно в целом медленный по сравнению с другими операциями. Так что, если вы должны его использовать, это не повредит. Однако я бы постарался не называть его больше, чем это действительно необходимо! : -)
В вычислениях на самом деле не существует такой вещи, как «дорогостоящая операция», если только вы не учитываете, что это дорого по сравнению с.
Например, в реальном мире это было бы 2.000 долларов .000 за объект будет дорого? Что, если это цена Багамских островов? Тогда это будет дорого? А что насчет пакета молока? Это дорого?
Вам нужно учитывать, является ли File.Exists
дорогим с точки зрения общей операции, которую вы собираетесь выполнять, и есть ли у вас на самом деле какие-либо альтернативы.
Если у вас нет альтернатив, имеет ли значение, дорого он или нет?
Например, если вы выполните 1 проверку, существует ли файл, а затем, если он есть, вы загрузите его и потратите час обработки, то я бы предположил, что это не будет считаться дорогостоящим.
Однако,
Я не думаю, что это ( файловые операции в значительной степени оптимизированы и кэшируются на большинстве ОС), и большинство других операций, скорее всего, будут виноваты здесь (сокеты, доступ к БД, общая обработка и т. д.). Но, как обычно, лучший способ - профилировать свое приложение и посмотреть, является ли оно точкой доступа.
Лучше всего запустить несколько тестов в вашей среде. У меня есть приложение, которое может работать со скоростью 10 000+ в секунду без сбоев в работе моих систем. Я считаю, что это довольно быстро.
File.Exisits
с обработчиком открытия файла findFirstFile kernel32.dll. Если полученный дескриптор недействителен, возвращается false. Если он действителен, он заполняет структуру данных всеми вещами, такими как LastAccessTime, CreationTime, размер файла и так далее. А потом верните истину. Ничего не блокирует.