CODEWITHSUNDEEP
c#performancecoding-styleapp-config
nawfal
nawfal

Reputation: 73163

Is reading app.config expensive?

No question I am yet to be hit by any read speed bottleneck. I am asking to know; if reading app.config frequently is a bad programming choice. I have known of database operations getting expensive.

In my case I am not reading my own application's app.config, but of another project's, like this: 

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;
}

Scenario: I have a manager class (and only one such class) where I have to read few values (3 to 4) from a config file specified by a physical path, but many times. Need I have few member variables to store the values from app.config file? What would be the best approach. Thanks.

Upvotes: 31

Views: 13865

Answers (5)

Tim Schmelter
Tim Schmelter

Reputation: 460028

I'm sure that all configuration files(web.config or app.config) are cached by default, so you don't need to create a static class that holds all values or be afraid that the files are accessed permanently.

Here is some reading:

Regarding to your requirement to access another application's config file:

MSDN: "These methods(note: for client applications: ConfigurationManager.GetSection) provide access to the cached configuration values for the current application, which has better performance than the Configuration class."

In other words: Yes, you should cache it when it's not your own app's config file.

Upvotes: 21

Oded
Oded

Reputation: 498904

Anything that ends up with disk IO is expensive (definitely when talking about rotating media).

See What are the numbers that every computer engineer should know, according to Jeff Dean? on Quora to see the differences in speed.

If you are reading a file repeatedly, you should cache the results (in particular if the file does not change).

When using the default configuration, the .config file only ever gets read one time, at application startup and the results are cached in memory.

Update, example as requested:

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;
}

Assuming this lives in a class that has the lifetime of the application, you have now cached the configuration in memory for the lifetime of the application.

Upvotes: 6

Haymo Kutschbach
Haymo Kutschbach

Reputation: 3362

While the values from the app.config are being cached, frequently reading them in a multithreaded scenario may introduce a serious performance hit. If you have to access the config values concurrently, it will be better to use you own caching. You can derive a custom implementation from the AppSettingsBase class.

In general, wrapping the default config manager into an own implementation will be a good design decision in most cases. It holds you not only safe from changes to your (customer?) config settings names. But also gives you the flexibility to cache those values or get them from any other source which might be/get important.

Upvotes: 2

Min Min
Min Min

Reputation: 6218

Reading from app.config is only first time when you executed the application. After that, it will store this configuration in memory and read from it whenever you need access. That is why, changing in app.config won't affect for current running application.

Upvotes: 2

Henk Holterman
Henk Holterman

Reputation: 273169

You're not really doing I/O here, at least not directly.

Just assume the the Config system will cache the values, and only take action when you have a performance problem.

It's not worth cluttering up your code with DIY caching everywhere.

Upvotes: 3

Related Questions