By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,144 Members | 880 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,144 IT Pros & Developers. It's quick & easy.

Small dynamic objects and performance degradation.

P: n/a
What can I do to circumvent the performance degradation associated with
dynamic allocation and small objects? Thanks.
Jul 22 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a

"Jason Heyes" <ja********@optusnet.com.au> wrote in message
news:41**********************@news.optusnet.com.au ...
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

Jul 22 '05 #2

P: n/a
Jason Heyes wrote:
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

Jul 22 '05 #3

P: n/a
> 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.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jul 22 '05 #4

P: n/a
Jason Heyes wrote:
What can I do to circumvent the performance degradation associated with
dynamic allocation and small objects? Thanks.

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

bye,
'monster
Jul 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.