Several of my colleges and I recently began looking into how assemblies were loaded in the .NET CLR for a web application that we're working on. The application runs several instances within each of several application pools that all used the same set of large assemblies. What we found was, that since we'd paid little attention to how assemblies were loaded to that point, we had assemblies being loaded multiple times contributing to a huge memory footprint for the application.
Now with all that background information out of the way, we found that placing those large assemblies I mentioned above, along with all of their references in the GAC caused the CLR to load them as domain-neutral and thus share the same assemblies in memory across applications in the same application pool. This reduced our memory footprint per application pool somewhat and with several application pools running several applications made an impact to resource demands on our servers.
So what you might be asking, the moral of this story and the reason I decided to blog about it is that all too often we as developers or systems administrators don't pay enough attention to how our applications are deployed and configured. We take for granted all the things that the .NET framework does for us and our application performance and users suffer because of it. Now, deploying assemblies in the GAC isn't what i'm recommending for every solution and we didn't end up putting all of our application assemblies in the GAC. You should however take some of the information i've provided above, research a bit for yourself and evaluate your application to optimize it's use of resources which can translate to a big performance impact for your end users.