How is ConfigurationSettings class implemented?

[Guest]

I get AppSettings property System.Configuration.ConfigurationSettings on each method call in order to determine an entry from machine.config in a stateless class

I would like to know how much overhead is involved in doing that. Does ConfigurationSettings.AppSetting actually do IO to read machine.config or it caches the data somewhere

Has anybody profiled it?

Thanks

-Stan

 

[Mitch Ruebush]

Hi Stan,
If it is like the web.config file then it is not read from memory. You can
gain about a 3x performance gain if you do use something like the
System.Web.Caching.Cache object to hold the values. I would create a
"Settings" object to wrap the Cache object so you could change its
implementation in the future, while minimizing the impact to your
application. This would have private methods that would try to read the
value from the Cache object, if it wasn't there it would insert it into the
Cache object from the ConfigurationSettings.AppSetting. Provide a public
function or property on your Settings object like getConnStr() to access the
values.

Mitch

Mitch Ruebush
Microsoft Regional Director - http://www.microsoftregionaldirectors.com
Visual Developer - .NET MVP -
Architect | Evangelist | Teacher
Online Consulting, Inc. - http://www.onlc.com
MCSD, MCAD, MCDBA, MCSE, MCT

I get AppSettings property System.Configuration.ConfigurationSettings on

each method call in order to determine an entry from machine.config in a
stateless class.

I would like to know how much overhead is involved in doing that. Does

ConfigurationSettings.AppSetting actually do IO to read machine.config or it
caches the data somewhere?

 

[Guest]

Mitch

The only problem is that half of my components run under Windows scheduler, therefore I cannot use caching

If it is 3x performance degradation, why MS recommends in all white papers to keep connection strings in *.config files

If framework really does IO each time, it is pretty bad, because I get config string from AppSettings on each method call..

Of course it depends on ratio between getting config settings and actual method run time. In my case the methods run time is relatively short (10 - 100 ms), so the impact of using ConfigurationSettings may be significant..

Thanks for your reply

-Sta

----- Mitch Ruebush wrote: ----

Hi Stan
If it is like the web.config file then it is not read from memory. You ca
gain about a 3x performance gain if you do use something like th
System.Web.Caching.Cache object to hold the values. I would create
"Settings" object to wrap the Cache object so you could change it
implementation in the future, while minimizing the impact to you
application. This would have private methods that would try to read th
value from the Cache object, if it wasn't there it would insert it into th
Cache object from the ConfigurationSettings.AppSetting. Provide a publi
function or property on your Settings object like getConnStr() to access th
values

Mitc

Mitch Ruebus
Microsoft Regional Director - http://www.microsoftregionaldirectors.co
Visual Developer - .NET MVP - http://mvp.support.microsoft.com
Architect | Evangelist | Teache
Online Consulting, Inc. - http://www.onlc.co
MCSD, MCAD, MCDBA, MCSE, MC

I get AppSettings property System.Configuration.ConfigurationSettings o

each method call in order to determine an entry from machine.config in
stateless classConfigurationSettings.AppSetting actually do IO to read machine.config or i
caches the data somewhere

 

[Richard Grimes [MVP]]

I get AppSettings property System.Configuration.ConfigurationSettings on

each method call in order to determine an entry from machine.config in a
stateless class.

I would like to know how much overhead is involved in doing that. Does

ConfigurationSettings.AppSetting actually do IO to read machine.config or it
caches the data somewhere?

It caches. The first time a section is read in an AppDomain the
configuration handler for that section is called and passed just the XML for
that section. The configuration handler creates a configuration object
appropriate to the section (see the <configSections> in the machine.config
file). This object is cached in a hash table. The next time the section is
requested in the *same* AppDomain the hash table is consulted and the cached
object is returned.

You can confirm this yourself by decompiling the code, or (better) take a
look at the Shared Source CLI (Rotor).

Has anybody profiled it?

Yes, but not to get timings, I profiled to see the methods that are being
called and when. I have also read through most of the SSCLI code relevant to
config files.

Richard

 

[Richard Grimes [MVP]]

Hi Stan,
If it is like the web.config file then it is not read from memory. You can

The web.config files for ASP.NET are consulted in a different way to how
config files for stand alone processes are accessed.

Standard config files are cached in memory on a per section basis for each
AppDomain. That is, each configuration object is cached in a hash table as
they are read and are returned on subsequent calls. Its easy to prove this,
because if you change the settings in the config file they are only picked
up when a new AppDomain is created (usually that means that the process is
restarted).

Richard