Small dynamic objects and performance degradation.

[Jason Heyes]

What can I do to circumvent the performance degradation associated with
dynamic allocation and small objects? Thanks.

 

[Howard]

What can I do to circumvent the performance degradation associated with
dynamic allocation and small objects? Thanks.

If you know how many of these items you might need (or the MOST you might
need), you could pre-allocate a pool of them at startup, and draw from that
pool. Or, you could allocate a larger chunk of memory, enough to hold a
number of the objects, and use "placement new" to construct the objects in
specific locations within that chunk. (But you might consider whether
you're actually observing any performance degradation, and profile it,
before you try to solve a problem that may not really exist.)

-Howard

 

[Puppet_Sock]

What can I do to circumvent the performance degradation associated with
dynamic allocation and small objects? Thanks.

To put some flesh on the bones Howard provided:

You allocate a bunch of the small items in a pool some place.
There are many ways of doing this. One way is to put them in
a global object that does the maintenance for you. The global
object keeps them in an array or a vector or whatever is most
appropriate to your task. It will have various functions as
required to set things up, get the next available object,
give back an object, etc. Basically, you've got a special
purpose memory manager. Which brings up another way of
approaching this, namely to overload new and delete.

Then you need a "named constructor" to go with. That's just a
function in the class of the small object that allows you to
re-initialize the small object as required.

So, you allocate the global pool once. Then, as required, you
re-initialize each object to new values, possibly passing back
either a reference or a pointer, or possibly an iterator if
you have the pool in a standard container.

How fancy you get with this depends on your needs. For example,
you might do something along the lines of keeping the objects
along with a reference count of some kind, so you can keep track
of whether a given member of the pool is in use. Or you could
get really fancy and allow things like allocation of arrays of
the small object, initialization of ranges, etc.

And, as always with optimization issues, it is important to
actually test whether a new method actually works faster than
old methods. Get out your stop watch, design a typical test
case, and see if the pool actually makes things faster.
Socks

 

[jcoffin]

What can I do to circumvent the performance degradation associated

with dynamic allocation and small objects?

You might want to pick up a copy of _Modern C++ Design_ (Andrei
Alexandrescu), which contains a complete implementation of a
small-object allocator and a fair amount of discussion about
implementing and using same.

 

[Swampmonster]

What can I do to circumvent the performance degradation associated with
dynamic allocation and small objects? Thanks.

Have a look at boost:ool - maybe that saves you some time.

bye,
'monster