I'm confused by a couple of things in your response.
[quoted text, click to view] > I am working on an app that MUST be responsive at all times. Our
> application
> has a very large managed memory footprint (> 1GB of small objects).
How much memory is available on the machine? Bear in mind that .net
allocates 2gigs of address space max. At that rate, with other apps running
on the box, you should be passing the recommended 60% memory limit. Pass
that point and you should be experiencing an unstable app IMO.
We are
[quoted text, click to view] > seeing that our app hangs for a couple of seconds when the garbage
> collector
> compacts the heap.
GC works by copying live objects, with such extreme memory pressure as your
app is placing on the system, 2 seconds is reasonable.
[quoted text, click to view] > Pinning many small
> objects in the regular heap causes poorer performance than allocating many
> large objects in the LOH.
What benefit do you see by pinning managed objects?
[quoted text, click to view] > Is there any way to avoid the ~2 second pause caused by the compacting
> process?
I'd like to know why the app is so memory intensive before dishing out
advice. Maybe you can go into some more detail about the application and the
footprint size. I've never really seen such a demanding memory requirement
for run of the mill type applications.
--
Regards,
Alvin Bruney
[ASP.NET MVP
http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here...
http://tinyurl.com/27cok [quoted text, click to view] "Frank" <google@xemaps.com> wrote in message
news:10gq8s591a6f86b@corp.supernews.com...
> Alvin,
>
> I am working on an app that MUST be responsive at all times. Our
> application
> has a very large managed memory footprint (> 1GB of small objects). We are
> seeing that our app hangs for a couple of seconds when the garbage
> collector
> compacts the heap. Since our app must remain responsive we would rather
> take
> the hit of allocating on the LOH and avoid the "compacting" phase all
> together. The LOH has been described as being more similar to the C++
> heap,
> which is what we want. However, we want to try to avoid making calls into
> unmanaged code for all our allocations and deallocations. Pinning many
> small
> objects in the regular heap causes poorer performance than allocating many
> large objects in the LOH.
>
> Is there any way to avoid the ~2 second pause caused by the compacting
> process?
>
> Thanks,
>
> Frank
>
> "Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
> news:OcGsK$9dEHA.1280@TK2MSFTNGP10.phx.gbl...
>> What's the reason for this? Large objects need to live on the large
>> object
>> heap, small objects don't need to.
>>
>> --
>> Regards,
>> Alvin Bruney
>> [ASP.NET MVP
http://mvp.support.microsoft.com/default.aspx]
>> Got tidbits? Get it here...
http://tinyurl.com/27cok >> "Frank" <google@xemaps.com> wrote in message
>> news:10got60mls6p3ff@corp.supernews.com...
>> > Does anyone know if it is possible to force a small object to be
> allocated
>> > on the Large Object Heap (LOH)?
>> >
>> > Thanks,
>> > Frank
>> >
>> >
>>
>>
>
>
