> Looks like I was in the right track in my last email - I would have > thought that the Cache would have taken the size of the object > into account - it looks like they intended to take this into account >( from the method names and structure) account but could not do > it :) .
AllocationProfiler [1] does a full trace of heap references, so you could use the same process to work out how many child objects that a particular object was keeping alive. You'd need to do a full heap trace to determine the relationship between all the references, and use some weighting to determine the real sizeof value, so if 10 objects in the cache had a reference to a 1000 byte object, each takes a 100 byte sizeof hit. There would be plenty of complexities - what if an object outside the cache also had a reference to a child object - there would be not point letting the cached object die, because the child object would still live. You'd need to implement something like a weighted sizeof that included all child objects, but excluded those child objects that were also held be a strong reference in a non-cached object. A runtime suspension would be required, so you'd need unmanaged code to do this. In essence, you'd have a pseudo-garbage collection for the cache. Getting all this right would be a big, big job. No wonder the ASP.NET team excluded the sizeof criteria for letting objects go. Nick [1] http://www.gotdotnet.com/userarea/filedetails.aspx?FileName=AllocationProfil er.zip You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
