Является ли чтение app.config дорогим?

Нет сомнений, что меня еще не поразило узкое место в скорости чтения. Я прошу знать; если чтение app.config часто является плохим выбором программирования. Я знаю, что операции с базой данных становятся дорогими.

В моем случае я не читаю собственное приложение app.config, а другое другого проекта:

private string GetAppConfigValue(string key)
{
    ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
    fileMap.ExeConfigFilename = GetConfigFilePath();
    Configuration appConfig = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
    return appConfig.AppSettings.Settings[key].Value;
}

Сценарий: у меня есть класс менеджера (и только один такой класс), где мне нужно прочитать несколько значений (от 3 до 4) из файла конфигурации, указанного физическим путем, , но много раз. Нужно ли иметь несколько переменных-членов для хранения значений из файла app.config? Какой был бы лучший подход. Спасибо.

Ответ 1

Я уверен, что все файлы конфигурации (web.config или app.config) кэшируются по умолчанию, поэтому вам не нужно создавать статический класс, который содержит все значения, или бояться, что файлы будут доступны постоянно.

Вот несколько примеров:

Относительно вашего требования доступа к другому файлу конфигурации приложения:

MSDN: "Эти методы (примечание: для клиентских приложений: ConfigurationManager.GetSection) доступ к кэшированным значениям конфигурации для текущего приложения, которое имеет лучшую производительность, чем класс конфигурации".

Другими словами: Да, вы должны кэшировать его, если это не ваш собственный конфигурационный файл приложения.

Ответ 2

Все, что заканчивается диском IO, дорого (определенно, когда речь идет о вращающихся носителях).

См. Каковы числа, которые каждый компьютерный инженер должен знать, согласно Джеффу Дину? в Quora, чтобы увидеть различия в скорости.

Если вы повторно читаете файл, вам следует кэшировать результаты (в частности, если файл не изменяется).

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

Обновить, пример по запросу:

private Configuration appConfig;

private Configuration GetConfig()
{
    if (appConfig != null)
        return appConfig;

    ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
    fileMap.ExeConfigFilename = GetConfigFilePath();
    appConfig = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

    return appConfig;
}

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

Ответ 3

Вы действительно не делаете I/O здесь, по крайней мере, не напрямую.

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

Не стоит загромождать ваш код с помощью кэширования DIY везде.

Ответ 4

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

Ответ 5

Пока значения из app.config кэшируются, часто их чтение в многопоточном сценарии может привести к серьезному поражению производительности. Если вам нужно одновременно получить доступ к значениям конфигурации, лучше использовать собственное кэширование. Вы можете получить пользовательскую реализацию из класса AppSettingsBase.

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