Накладные расходы на файл / Directory.Exists в геттере?

Question

Накладные расходы на файл / Directory.Exists в геттере?

2

У меня есть класс, который имеет несколько свойств, которые ссылаются на расположение файлов/каталогов на локальном диске. Эти значения могут быть динамическими, и я хочу убедиться, что в любое время, когда они будут доступны, я проверю, что он существует первым, без необходимости включать этот код в каждый метод, который использует значения.

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

Я знаю, что, как правило, не очень рано оптимизировать слишком рано, но я предпочел бы, чтобы эта ошибка была проверена на месте, прежде чем я вернусь и удалю ее из получателя и добавлю ее повсюду.

Разъяснение:

Файлы/каталоги, на которые указывают свойства, будут использоваться System.Diagnostics.Process. я не буду напрямую читать/записывать эти файлы/каталоги, я просто хочу убедиться, что они существуют до того, как я создаю дочерний процесс.

Jason Miesionczek 19 фев. 2009, в 14:16

Источник

Теги:

c#

4 ответа

2

Допустимо, что путь существует в точке, которую он проверяет, но перемещается/удаляется между ним и операцией на нем.
- Возможно, вы уже знаете это и соглашаетесь с риском, но так, чтобы вы знали об этом.
Если вы все равно это сделаете, неважно, находится ли это в свойстве или нет, какая именно степень детализации вашей проверки (один раз за операцию или один раз за группу операций)
Если вы используете нестатические операции FileInfo, имейте в виду, что этот объект будет кэшировать его представление в файловой системе.
- Это может быть полезно для вас, поскольку вы можете контролировать, как часто кеш обновляется с помощью метода Refresh(), или это может привести к возможным ошибкам в вашем коде.
Обычная попытка сначала, прежде чем беспокоиться о рекомендации по эффективности, но вы указываете, что знаете об этом.

ShuggyCoUk 19 фев. 2009, в 12:30

2

Если вы повторно используете объект, вы должны использовать класс FileInfo vs статический класс File. Статические методы класса File делают возможную ненужную проверку безопасности каждый раз.
FileInfo - DirectoryInfo - File - Directory

EDIT:

Мой ответ все равно будет применяться. Чтобы убедиться, что ваш файл существует, вы бы сделали что-то подобное в своем getter:

if(File.Exists(string))
//do stuff
else
//file doesn't exist

ИЛИ

FileInfo fi = new FileInfo(fName);
 if (fi.Exists)
//do stuff
else
//file doesn't exist

Правильно?

Я говорю, что если вы зацикливаете эту логику на тысячи раз, используйте экземпляр FileInfo VS статический Файл, потому что вы получите отрицательную производительность если вы используете статический метод File.Exits.

cgreeno 19 фев. 2009, в 11:47

0

Пожалуйста, смотрите мое разъяснение выше.
Jason Miesionczek 19 фев. 2009, в 13:10

2

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

private Dictionary<string, bool> _directories = new Dictionary<string, bool>();

private void CheckDirectory(string directory, bool create)
{
  if (_directories.ContainsKey(_directories))
  {
    bool exists = Directory.Exists(directory);
    if (create && !exists)
    {
      Directory.CreateDirectory(directory);
    }
    // Add the directory to the dictionary. The value depends on
    // whether the directory previously existed or the method has been told
    // to create it.
    _directories.Add(directory, create || exists);
  }
}

Впоследствии просто добавить те каталоги, которые не существуют, итерируя этот список.

Pete OHanlon 19 фев. 2009, в 11:21

Ещё вопросы

Пожалуйста, смотрите мое разъяснение выше.

philsquared · Accepted Answer · 2009-02-19T12-50-00.000Z

Все, что не простой поиск или вычисление, должен идти в методе, а не в свойстве. Свойства должны быть концептуально похожими на простое обращение к полю - если есть какие-либо дополнительные накладные расходы или вероятность сбоя (и IO - даже проверка файла существует - не пройдет тест на оба счета), то свойства не являются правильным выбором.

Помните, что свойства даже вызывают отладчик при просмотре состояния объекта.

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