4

When implementing an elementary data structure like stack, queues, linked list et al. should I create a resource pool(of nodes) by dynamically allocating memory in bunch or should I allocate memory separately every time I need a node?

Vaibhav Bajpai
  • 16,374
  • 13
  • 54
  • 85

2 Answers2

3

This entirely depends on your goals. By default (i.e. unless you really need to do otherwise), just do a normal allocation for each next node.

Memory pools as compared to just allocating nodes:

  • Make allocation faster. Depending on underlying allocation mechanism, sometimes significantly faster.

  • Usually less memory fragmentation, though this may not be a problem with some allocators.

  • Major drawback: waste memory on reserved, but not used nodes. This is very important if you use data structure indiscriminately (e.g. 1000s of instances) as opposed to just having a couple of instances.

Because of the drawback, memory pools are not suitable for generic situations.

In C++ all standard containers have an allocator template parameter.

1

It's a basic time vs. space trade-off. Chose based on what is more important to you:

If you allocate the pool in advance, then your runtime element insertions will be -- on average -- optimized for speed, i.e. constant time, i.e O(1). "On average" means that most insertions will be constant time, except those that hit the maximum and require expanding the pool, which are linear time, O(n). You also risk wasting some memory if you end up not using the whole pool.

If you do real-time allocation of every new node, you will always have constant-time insertion, but in this case, the constant time is a little longer than the constant time above, because you not only have to put a value into a memory location, but you also have to first allocate the memory location. Also, this method does not waste any memory by reserving memory locations in advance.

In most situations, I think real-time allocation is sufficiently efficient time-wise that I don't see why you'd use the pooled approach, unless your application requires extreme average speed or you do huge numbers of insertions.

Blah0x7B9
  • 220
  • 2
  • 9
  • Forgot to say: another reason to use the pooled approach is if for some reason you *need* consecutive memory locations, i.e. like in Java's implementation of ArrayList. But this was not among the data structures you listed in your example. – Blah0x7B9 Sep 26 '12 at 03:49