4

When reading the Improving .NET Application Performance and Scalability I have bumped into this under "Improving Managed Code Performance/Garbage Collector Guidlines:

Avoid preallocating and chunking memory.

But the book never goes into explaining as to why preallocating is bad or what the Chunking really means in light of GC optimization.

Can someobody shed more light on the issue and explain to me why the 2 are bad and what do they really mean in terms of using GC with .net?

http://www.microsoft.com/downloads/en/details.aspx?FamilyId=8A2E454D-F30E-4E72-B531-75384A0F1C47&displaylang=en

dexter
  • 7,063
  • 9
  • 54
  • 71

2 Answers2

7

Pre-allocating memory is a technique that doesn't scale well. Chunking may push the allocation in the Large Object Heap. Either will make you use memory needlessly. Trust the garbage collector, allocate when you need it.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 2
    Of what? The point is that you *don't* use this kind of code. – Hans Passant Mar 31 '11 at 20:08
  • Exactly...what kind of code? I guess I don't know what allocation is in terms of using the GC... – dexter Mar 31 '11 at 20:09
  • 1
    You allocate with the *new* keyword. – Hans Passant Mar 31 '11 at 20:12
  • 1
    +1 I think the bigger issue isn't that pre-allocating is always bad [e.g. sometimes it *might* be okay, such as a buffer or List (with initial Capacity) that's *expected* to fill up, not excluding a better solution entirely] -- but rather that the .NET GC is "quite good" so these techniques which may have been good under non-managed programs (malloc is *very slow* compared to a GC alloc!) don't necessarily still apply. Oh, and benchmark first :P –  Mar 31 '11 at 20:12
  • @Hans, duh, was really expecting to read something more esoteric. Well if the new is bad how do you write any code, go static all the way? – dexter Mar 31 '11 at 23:51
  • 1
    You really seem to miss the point on this. Of course *new* is not bad. It is bad to use it too early, preallocating, say, arrays that you will only use later. It is fairly common to do this in native code to try to micro-optimize the heap allocator and avoid heap fragmentation. It is just not a good thing to do when you have a garbage collector, it doesn't have the same kind of problems. – Hans Passant Mar 31 '11 at 23:58
3

It does have a few things to say about what the problems are. Page 198:

C++ programmers often allocate a large block of memory (using malloc) and then use chunks at a time, to save multiple calls to malloc. This is not advisable for managed code for several reasons:

  • Allocation of managed memory is a quick operation and the garbage collector has been optimized for extremely fast allocations. The main reason for preallocating memory in unmanaged code is to speed up the allocation process. This is not an issue for managed code.
  • If you preallocate memory, you cause more allocations than needed; this can trigger unnecessary garbage collections.
  • The garbage collector is unable to reclaim the memory that you manually recycle.
  • Preallocated memory ages and costs more to recycle when it is ultimately released.
Gareth McCaughan
  • 19,888
  • 1
  • 41
  • 62