Hello,
it was me who took a (quick) look at this. I'm not sure where you got your sizes from but often people quote figures shown in task manager, which can be a bit misleading - whilst tasks manager does show private working set, it doesnt break down what it consists of. Typically you can use process explorer to drill down, but in my case I started a new DotNetNuke 6 site and clicked through half a dozen pages whilst logged in as host.
At this point task manager showed ~ 151MB in used for the worker process. This of couse also has some app pool overhead (and the copy of the framework loaded to service it) which is quite a lot as I had a dedicated app poll - whereas if i had multiple sites that overhead is shared.
To validate the contents of the process I created a memory dump and loaded up WinDBG and added Psscor4 and examined the memory (!CLRUsage) and saw the following:
Number of GC Heaps: 2
Heap Size 0x3b3a010(62,103,568)
Heap Size 0x2fa13a8(49,943,464)
------------------------------
GC Heap Size 0x6adb3b8(112,047,032)
Total Commit Size 0000000006af7000 (106 MB)
Total Reserved Size 0000000099509000 (2453 MB)
As you can see the commit size is much smaller that the overall size (as the non .net memory such as the c++ for the app pool overhead is not inclded)– and looking at the heaps the 1
st is probably dotnetnuke and the 2
nd is the apppool and framework. Whilst the first one is higher than I'd like I dumped the cache, httpruntime and datatables and there wasn't anything I wouldnt expect. There are quite a lot of large strings and regular expression usage and this is definately something I'll want to examine at a later date to see if we can reduce this (or in the case of regular expressions use compiled ones to see if that saves memory), but overall I don't see anything to concern me here.
As Ash says, I'm speculating that the increase in usage was caused by the change in language, and the resulant change in compiler from vbc.exe to csc.exe and the fact that even through the c# compiler was used namespaces such as microsoft.visualbasic.compatibility and microsoft.visualbasic.compilerservices were still in the app pool as the only way to remove loaded objects is to recycle the application pool. If you recycle the application pool you should see the size drop down (as long as you dont have other sites that use vb.net)
Thanks,
Cathal