Re: Strategy for caches & GC
- From: devdude <rottyguy70@xxxxxxxxx>
- Date: Mon, 21 Apr 2008 04:05:19 -0700 (PDT)
Barry, thanks for the response, see inline.
On Apr 21, 6:35 am, Barry Kelly <barry.j.ke...@xxxxxxxxx> wrote:
It sounds like you need a more aggressive cache expiration policy. As
Rico Mariani [Google] likes to say, a poorly implemented expiration
policy is just a memory leak by another name. What you say makes me
think that the cache is getting a too-low hit rate, so it needs throw
away most of it too often. Perhaps it shouldn't be caching much of this
stuff at all in the first place?
As mentioned, this was stress testing so I wanted to push the cache to
the size limit and see how it would respond while scavenging.
When dealing with large amounts of data, I find GC is often not the best
way to go. I end up writing manual allocators for byte arrays. This
makes most sense when the data you're caching is in fact a byte array,
or other value-typed array, of course. However, I still allocate those
byte arrays from the .NET GC. It's just that they're all over the large
block limit (80K or so), and I carefully recycle them through a pool.
Can you explain this further? Do you mean you alloc a huge block of
memory to insure it sits in the LOH and suballocate from there (ala
your own memory management on the managed heap?) If so, how does the
suballocations look? Does C# have a placement new like C++?
BTW, you can still do manual memory allocation in C#, using the Marshal
class or by writing the PInvoke signatures yourself. However, I'd take a
closer look at your expiration policy before I'd go off and try and
reimplement a cache.
How does one serialize/deserialize managed objects onto the native
heap if these managed objects can be derived from a common base (e.g.
CacheItem<-MyCacheItem, CacheItem<-MyOtherCacheItem)? I'm (also)
wondering if memory fragmentation will start occurring in the native
heap?
Thanks!
.
- Follow-Ups:
- Re: Strategy for caches & GC
- From: Barry Kelly
- Re: Strategy for caches & GC
- References:
- Strategy for caches & GC
- From: devdude
- Re: Strategy for caches & GC
- From: Barry Kelly
- Strategy for caches & GC
- Prev by Date: Re: Strategy for caches & GC
- Next by Date: Re: Strategy for caches & GC
- Previous by thread: Re: Strategy for caches & GC
- Next by thread: Re: Strategy for caches & GC
- Index(es):
Relevant Pages
|