Is caching using Application slower or more problematic than using Global.asax.cs static variable?

We have a Webforms application that stores a bunch of settings and terminology mappings (several hundred) that are used throughout the application.

http://www.dotnetperls.com/global-variables-aspnet makes these assertions:

The Application[] collection .... may be slower and harder to deal with.

the Application[] object ...is inefficient in ASP.NET.

Is this recommended? Yes, and not just by the writer of this article. It is noted in Professional ASP.NET by Apress and many sites on the Internet. It works well

So I am wondering if these statements are true. Can anyone elaborate on why using Application is slower or what kind of problems can crop up if you use Application? I am sort of assuming that any problems or slowdowns might only surface under production loads, so that is why I am asking for real world experience, rather than just benchmarking myself.

I am aware that there are many alternatives to caching (HttpRuntime.Cache, memcached, etc) but specifically I want to know if I need to go back and rewrite my legacy code that uses Application[]. Specifically if in any way I am i开发者_开发问答ncurring a performance penalty I would want to get rid of that.

---

How are you saving these settings? I would recommend the web.config

If you're using the web.config to store these settings (if they're application variables that's a solid place to start), then no need for Application variables.

I try to steer clear of the Application level variables because they are way more expensive than Session variables.

Also, variables in the web.config / app.config files can change without having to change code and/or recompile your project.

Application class (global variables) only exist in ASP.NET to help with backwards compatibility with classic ASP, you could say it's deprecated.

Another thing you could look into would be caching your settings so you're not always reading from disk.