0

In my application there are some cases that relatively small objects, (max 50 bytes) e.g. message classes for logging purposes, must be created and freed (by GC) frequently during the execution of the program. So I am worried about the overhead of dynamic allocation of these objects. As stated in this question there are some usable fast memory allocators for native code.
Is there a concept of fast memory allocation in .Net or is fast memory allocation needed in .Net? If not what can be used to speed up that kind of implementation? (Maybe some kind of a preallocated object pool.) Should I worry about the overhead?

Community
  • 1
  • 1
ali_bahoo
  • 4,732
  • 6
  • 41
  • 63

3 Answers3

3

You should not worry about the overhead unless and until your profiler gives you hard data to support the worrying.

I suppose that you might be able to implement an allocator using unsafe code, but would the hair-pulling and the effort be worth it? You have to profile to know.

Jon
  • 428,835
  • 81
  • 738
  • 806
  • So when I profile, how should I know that my implementation is enough fast? I don't have any other alternative to compare to. – ali_bahoo Apr 12 '11 at 22:23
  • 3
    Here's a quote I just made up: "If the customer doesn't complain, it's fast enough". – Jon Apr 12 '11 at 22:26
2

As it behooves a well designed memory allocator, there is only one way to allocate garbage collected memory. It is very fast, allocating merely requires adjusting a pointer. Much faster than the allocator that native code has to use. Which has a much more difficult job to do, once native memory is allocated it cannot be moved anymore. Which makes it hard to write an allocator that doesn't suffer from fragmentation. The counter-measures add overhead. Not an issue in a GC heap, it can compact.

You cannot improve on the speed of the GC allocator.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks for the enlightening, technical answer. I wish I could upvote more than once – ali_bahoo Apr 13 '11 at 07:13
  • In practice the speed of allocation alone doesn't matter. It's the combined cost of allocation and collection that matters. And estimating the collection cost is complicated. – CodesInChaos Apr 13 '11 at 07:59
  • @CodeInChaos: In native code, for some cases it does matter. The purpose of this question is to learn if managed allocation is like native allocation. Thanks to @Hans I know that GC allocation is already fast. I am sure he has something to tell for your comment. – ali_bahoo Apr 13 '11 at 13:38
1

If the objects are small and short lived I wouldn't worry too much. They most likely get collected with the Gen0 GC, which is usually relatively cheap.

You can implement a pool, but in my experience this is only necessary if you allocate large objects(If I recall correctly objects are placed on the large object heap if they're bigger than about 80kB) or very many(many millions per second) objects.

So first implement it normally. And only if you see that your program spends a lot of time in the GC you should worry about your allocations. Most likely you're thinking about a premature optimization.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
  • I don't think it is a premature optimization. Because it is a fact that those allocators, provided in the linked question, are much more faster than traditional `malloc()`, so are much more appropriate for a task scheduling or messaging implementation. Task scheduling of Intel TBB does purely rely on the speed of its allocator. – ali_bahoo Apr 12 '11 at 22:21
  • So how many objects do you need to allocate per second? Allocation itself is practically free in .net, Collection in the problem. And switching in a Pool if profiling really shows that collection is your bottleneck is easy. I still say you should write it using the standard allocation first and only do more complicated stuff if necessary. – CodesInChaos Apr 13 '11 at 07:57