Bruno,

Like you said, perhaps our app is not suitable for a managed environment.

I am assuming the LOH will become fragmented, whether you allocate large
objects or small objects (perhaps more quickly with small objects). But even
if we use an unmanaged environment (e.g., C++ heap) we would still have a
fragmentation problem. In other words, the C++ heap would fragment just as
easily as the C# LOH. So, if we are going to contend with fragmentation
anyway, may as well do it in C# where you also get the benefits of
generational garbage collection.

I think it would be a great feature if .NET would let you specify which heap
to allocate on. If that happened, the LOH should be called the
No-Compact-Heap. It would also be nice if you could specify/inject a custom
garbage collector for an AppDomain.

-Frank

As Bruno says, you may have to look at things like pre-allocation. If you
know you will need a lot of instances of SmallObject, it may improve your
performance a lot to allocate roughly the required number at startup. Then,
instead of instantiating new objects when needed, you reuse the old ones. By
allocating at startup, you put the memory at the beginning of the heap, and
hence there is little chance it will have to move during a heap compaction.

Niall