Caching and performance

Configuration providers cache bound settings for each (type, source) pair where sources are compared by reference. Caching ensures a solid performance level: only the first Get call is somewhat expensive while all the subsequent ones are extremely cheap. The cache is automatically updated when the underlying source issues new data.

provider.Get<MySettings>(); // may block and incurs binding costs

provider.Get<MySettings>(); // instantly returns a cached object

// ... the source issues a data update ...

provider.Get<MySettings>(); // instantly returns the old cached object

// ... the cache is automatically updated in background...

provider.Get<MySettings>(); // instantly returns an updated cached object

Due to caching, configuration provider instances should be reused as much as possible. Ideally there should be just one singleton instance in the application.

Special care should be taken when using Get and Observe methods with short-lived source instances passed on per-call basis. This could cause poor performance due to cache misses and even lead to cache overflow events. Overflow events may cause violations of error handling guarantees. Default cache capacity is 50 but can be tuned in provider settings:

var settings = new ConfigurationProviderSettings 
{
    MaxSourceCacheSize = 100_000
};

var provider = new ConfigurationProvider(settings);

This pitfall is easy to fall into as all of the source-related extensions (combine, scope, transform, etc) return decorators that are treated as distinct sources. The only viable solution is to cache these derivative sources.

Related pages

pageConfiguration providerpageLog settings updatespageObtain settings from providerpageObserve settings via provider