1

I have an ASP.NET app hosted for many domains and all are mapped to the same root folder, i.e., code-base. Will it take less memeory if I load the DLLs currently located in bin folder into GAC? Any special code considerations to take to load DLLs into GAC for sharing (other than security aspect)?

Is there any way of making DLLs sharable in .NET environment?

Thank you

Kris

BradleyDotNET
  • 60,462
  • 10
  • 96
  • 117
Kris
  • 13
  • 3
  • Found more discussion on this at: [link](http://stackoverflow.com/questions/945273/speed-increase-by-using-the-global-assembly-cache) – Kris May 19 '11 at 14:33

3 Answers3

3

Putting the DLLs in the GAC will not help with memory usage. The DLLs still need to be loaded into each app domain, and they will not be in shared memory.

The point of using the GAC is to centralize distribution of assemblies - so changes can be managed in one place. Sounds like this is something that you could still benefit from.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • As far as distribution is concerened, it is same even now, since I have only one copy in bin folder used by all apps. – Kris May 18 '11 at 21:59
  • we have same setup, we went to the trouble of converting the app's [appcode] to a class library and deploying it to GAC, we thought it will use less server memory, seems NO, each app instance will eat up the same memory as (before we had the app_code in GAC), so can i safely say... the MYTH that putting code in GAC reduce memory is BUSTED? – visual Aug 08 '12 at 06:56
  • @Oded are you SURE they aren't loaded into a shared space? The well known memory profiler Tess Ferrandez says differently - https://blogs.msdn.microsoft.com/tess/2006/04/12/asp-net-memory-you-use-the-same-dll-in-multiple-applications-is-it-really-necessary-to-load-it-multiple-times/ – Dave Black Oct 09 '18 at 22:20
0

As Oded explained just putting them in the GAC won't help. What might help is putting them into the GAC and NGEN the assemblies. See here and here. Be sure to measure the different memory usages, load times and overall performance, because those can be negatively influenced by NGEN. See here and here.

Community
  • 1
  • 1
Lars Truijens
  • 42,837
  • 6
  • 126
  • 143
0

Actually, the accepted answer from @Oded and the other from @LarsTruijens are both
incorrect. Placing assemblies in the GAC DOES help reduce memory usage.

This is confirmed by Jeffrey Richter (from Wintellect who helped design the CLR with the .NET team) in his book CLR via C#:

Installing assemblies into the GAC offers several benefits. The GAC enables many applications to share assemblies, reducing physical memory usage on the whole....

It is also confirmed by Tess Ferrandez (Memory and Performance Guru from Microsoft's - https://blogs.msdn.microsoft.com/tess/2006/04/12/asp-net-memory-you-use-the-same-dll-in-multiple-applications-is-it-really-necessary-to-load-it-multiple-times).

Wherever possible strong name and install to the global assembly cache (GAC) any assemblies that are used by more than one ASP.NET application. This will reduce memory consumption.

I've also confirmed this myself by testing (WinDbg, Task Manager, and ProcExplorer) on a x64 WebAPI service as an example. You'd see that the Private Working Set is lower with the GAC'd app. In the case of NGen, you would again see the Private Working Set decreased. However, the Page Faults are also greatly reduced in the NGen'd app compared to the baseline (almost by half in my test). I saw no difference in Page Faults between the GAC'd app and non-GAC'd app.

Note that the best solution in some cases is to combine NGen and the GAC by installing NGen'd assemblies into the GAC. This optimizes memory usage between apps that share assemblies as well as providing a performance boost at application startup!

Dave Black
  • 7,305
  • 2
  • 52
  • 41