Is reading app.config expensive?

Question

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.

You could always cache `appConfig` in static value so that you only have to read app.config once. — jrummell, Mar 05 '12 at 15:20
@jrummell, thats right. My question is, is it the right way to go? Is there a performance hit? etc — nawfal, Mar 05 '12 at 15:21
How good is the network connection to the remote app.config? — Polyfun, Mar 05 '12 at 15:24
@nawfal. since its a **XML** based document, framework internally parse the document and definitly its a performance hit. For your information, in the latest .net framework all config files are **JSON** based instead of **XML** based. — Gowtham, Oct 01 '14 at 07:28
Reading an app config with ConfigurationManager will merge in the machine configuration which will add in a performance hit (although I believe this will be cached after the first access). You may want to write your own code to read the config file using XmlDocument and XPath if you know the config is in your file. — Adam, Nov 20 '17 at 01:31

Tim Schmelter · Accepted Answer · 2014-10-01T06:51:13.593

21

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.

edited Oct 01 '14 at 06:51

answered Mar 05 '12 at 15:29

Tim Schmelter

450,073
74
686
939

1

in my case the app.config is not of the same project's, but of another. Can you give a perspective in that sense? I mentioned it in the question. – nawfal Mar 05 '12 at 15:31
1

@nawfal: [MSDN](http://msdn.microsoft.com/en-us/library/system.configuration.configuration.aspx) says: "These methods(for client applications: [ConfigurationManager.GetSection](http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.getsection.aspx)) provide access to the cached configuration values for the current application, which has better performance than the Configuration class." In other words: you are right, you should cache it when it's not your own apps config file. (edited my answer accordingly) – Tim Schmelter Mar 05 '12 at 16:03
The MSDN comment about app config being cached does not mean that the non-app config won't be cached. I have tested by opening a non-app config, modifying it outside the program and reopening it. The second time I opened the file did not pick up my changes. – Adam Nov 20 '17 at 01:23

Oded · Answer 2 · 2012-03-05T15:45:35.563

6

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.

edited Mar 05 '12 at 15:45

answered Mar 05 '12 at 15:23

Oded

489,969
99
883
1,009

Oded, Is there a specific implementation to cache? Or just assigning to static variables will do? – nawfal Mar 05 '12 at 15:27
@nawfal - You can cache the whole `Config` object. – Oded Mar 05 '12 at 15:29
@Oded can you please provide a small example of caching in object. thanks – Zaki Mar 05 '12 at 15:38
Surely if you are reading a disk file repeatedly the *OS* will do the caching for you? – Martin Thompson Mar 05 '12 at 16:51
@oded: OK, I'll rephrase: until it's proven that the OS *isn't* caching well enough for your performance target, leave it to it. Otherwise you've potentially used up memory that could be better used. Premature optimisation and all that :) – Martin Thompson Mar 05 '12 at 20:14
1

@MartinThompson - Possibly, but config tends to take so little memory that is you do refer to it often it makes sense to just do it. I agree that one should measure before optimising, but this is such a simple thing to do and get right... – Oded Mar 05 '12 at 20:15

score 3 · Answer 3 · answered Mar 05 '12 at 15:25

3

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.

answered Mar 05 '12 at 15:25

H H

263,252
30
330
514

in my case the app.config is not of the same project's, but of another. Can you give a perspective in that sense? – nawfal Mar 05 '12 at 15:29
1

Hmm, yes I missed that. Maybe it's wise to keep the `appConfig` around, but it really depends on how many calls you make and the scope this is needed in. – H H Mar 05 '12 at 15:36

score 2 · Answer 4 · answered Mar 05 '12 at 15:25

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.

score 2 · Answer 5 · answered Mar 05 '12 at 15:43

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.

Is reading app.config expensive?

5 Answers5

Linked