overload new and delete for performance? (design)

[Chris E. Yoon]

I just want to hear people's opinions on this subject.

My application has lots and lots of short-lived objects that use
dynamic allocation/deallocation. After implementing its functionality,
I found out that much processing is spent for new/delete calls.
So, to improve its performance, I made a little factory-like class that
pre-'new's those short-lived objects and stores them in a linked list when
the program starts.

Every time I need an instance, I would do something like the following:

// instead of new
ShortLivedObjec t* slo = SomeFactoryLike Class::instance ()->getOne();
// instead of delete
SomeFactoryLike Class::instance ()->returnOne(slo) ;

I would retrieve an instance from the pre-allocated objects and set its
members, and when I'm done, I just push it back to the end of the list.
Okay, so that was my intial solution. But an article I read recommended
that I overload new and delete operators, as in the following.


class ShortLivedObjec t {
...
ShortLivedObjec t* _next;
static ShortLivedObjec t* _freelist; // pointer to free list

void* operator new(size_t); // overloaded new()
void operator delete(void*); // overloaded delete()
};


And use the _freelist for storage and recycling.

So, let's say the memory for the object is aligned correctly,
and in new(), memory will either be allocated (if _freelist is empty)
using malloc(), or it will just return pop the front of _freelist
and return its pointer.

In delete(), memeory will not be deallocated. Only its pointer will be
returned to the _freelist.



Now in my personal opinion, the first solution is simpler and safer.
You have less to worry about inheritance. You don't have to come up
with your own storage allocator. You don't have to worry about new[]
and delete[].

Yet, lots of people, including some of my coleagues, seem to be
using the latter technique. Are there any reasons for this? Or is it
just a personal preference?

[Karl Heinz Buchegger]

Re: overload new and delete for performance? (design)



"Chris E. Yoon" wrote:[color=blue]
>
>
> Yet, lots of people, including some of my coleagues, seem to be
> using the latter technique. Are there any reasons for this? Or is it
> just a personal preference?[/color]

The later is completely transparent to the user of your class.
This means: The user of your class uses new and delete as always.
If this turns out to be to slow you add the new and delete
operators to your class, recompile, and magically the application
runs faster. If on the other hand the systems memory allocator is
optimized by your vendor and gets faster, you simply remove the
new and delete operators, recompile, and the application has equal
or near equal performance as before with less code.

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Michiel Salters]

Re: overload new and delete for performance? (design)

cryptopanda@nav er.com (Chris E. Yoon) wrote in message news:<9c17f9dc. 0307220105.52fb 4cdc@posting.go ogle.com>...
[color=blue]
> My application has lots and lots of short-lived objects that use
> dynamic allocation/deallocation. After implementing its functionality,
> I found out that much processing is spent for new/delete calls.
> So, to improve its performance, I made a little factory-like class that
> pre-'new's those short-lived objects and stores them in a linked list when
> the program starts.
>
> Every time I need an instance, I would do something like the following:
>
> // instead of new
> ShortLivedObjec t* slo = SomeFactoryLike Class::instance ()->getOne();
> // instead of delete
> SomeFactoryLike Class::instance ()->returnOne(slo) ;
>
> I would retrieve an instance from the pre-allocated objects and set its
> members, and when I'm done, I just push it back to the end of the list.
> Okay, so that was my intial solution. But an article I read recommended
> that I overload new and delete operators, as in the following.
>
> class ShortLivedObjec t {
> ...
> ShortLivedObjec t* _next;
> static ShortLivedObjec t* _freelist; // pointer to free list
>
> void* operator new(size_t); // overloaded new()
> void operator delete(void*); // overloaded delete()
> };
>
>
> And use the _freelist for storage and recycling.
>
> So, let's say the memory for the object is aligned correctly,
> and in new(), memory will either be allocated (if _freelist is empty)
> using malloc(), or it will just return pop the front of _freelist
> and return its pointer.
>
> In delete(), memory will not be deallocated. Only its pointer will be
> returned to the _freelist.
>
> Now in my personal opinion, the first solution is simpler and safer.
> You have less to worry about inheritance. You don't have to come up
> with your own storage allocator. You don't have to worry about new[]
> and delete[].[/color]

The solutions are basically the same, despite what you say. Both contain
a number of pre-allocated memory chunks. One difference is in naming
the allocation and deallocation functions. new and delete happen to be
the conventional names. The other is internal; your function will assign
the "initial" value using operator= while the new/delete solution goes
through a proper ctor/dtor sequence. This allows you to share memory
pools for same-sized objects (as an invisible future extension).
[color=blue]
> Yet, lots of people, including some of my coleagues, seem to be
> using the latter technique. Are there any reasons for this? Or is it
> just a personal preference?[/color]

It's the Standard interface, which means the Standard Library can be
used with your class. std::auto_ptr<S hortLivedObject >::~auto_ptr can
only call ShortLivedObjec t::operator delete().

Regards,
--
Michiel Salters