overload new and delete for performance? (design)

Discussion in 'C++' started by Chris E. Yoon, Jul 22, 2003.

  1. 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
    ShortLivedObject* slo = SomeFactoryLikeClass::instance()->getOne();
    // instead of delete
    SomeFactoryLikeClass::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 ShortLivedObject {
    ...
    ShortLivedObject* _next;
    static ShortLivedObject* _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?
    Chris E. Yoon, Jul 22, 2003
    #1
    1. Advertising

  2. "Chris E. Yoon" wrote:
    >
    >
    > 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?


    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
    Karl Heinz Buchegger, Jul 22, 2003
    #2
    1. Advertising

  3. (Chris E. Yoon) wrote in message news:<>...

    > 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
    > ShortLivedObject* slo = SomeFactoryLikeClass::instance()->getOne();
    > // instead of delete
    > SomeFactoryLikeClass::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 ShortLivedObject {
    > ...
    > ShortLivedObject* _next;
    > static ShortLivedObject* _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[].


    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).

    > 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?


    It's the Standard interface, which means the Standard Library can be
    used with your class. std::auto_ptr<ShortLivedObject>::~auto_ptr can
    only call ShortLivedObject::eek:perator delete().

    Regards,
    --
    Michiel Salters
    Michiel Salters, Jul 23, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. HeroOfSpielburg
    Replies:
    1
    Views:
    377
    Alf P. Steinbach
    Aug 6, 2003
  2. Piotre Ugrumov
    Replies:
    3
    Views:
    362
    Nick Hounsome
    Jan 25, 2004
  3. Nimmi Srivastav
    Replies:
    1
    Views:
    693
    John Harrison
    Feb 1, 2004
  4. JanW
    Replies:
    2
    Views:
    432
    Ian Collins
    Jan 23, 2007
  5. Ying-Chieh Liao

    function overload (not operator overload)

    Ying-Chieh Liao, Oct 11, 2004, in forum: Perl Misc
    Replies:
    3
    Views:
    240
    Sherm Pendley
    Oct 11, 2004
Loading...

Share This Page