Q: Allocating memory correctly

Discussion in 'C++' started by Jakob Bieling, Dec 7, 2003.

  1. Hi,

    Whenever allocating memory using operator new or operator new[] I feel
    like I should only use it very sparingly, because otherwise memory is wasted
    (by additional overhead needed to manage all those allocations) which also
    loses some performance. I am specifically talking about many little
    allocations (approx. 16-512 bytes). Is my feeling about this justified?

    thanks!
    --
    jb

    (replace y with x if you want to reply by e-mail)
     
    Jakob Bieling, Dec 7, 2003
    #1
    1. Advertising

  2. Jakob Bieling

    Moonlit Guest

    Re: Allocating memory correctly

    Hi,


    "Jakob Bieling" <> wrote in message
    news:bqv2fm$jvf$01$-online.com...
    > Hi,
    >
    > Whenever allocating memory using operator new or operator new[] I feel
    > like I should only use it very sparingly, because otherwise memory is

    wasted
    > (by additional overhead needed to manage all those allocations) which also
    > loses some performance. I am specifically talking about many little
    > allocations (approx. 16-512 bytes). Is my feeling about this justified?
    >

    Typically new has to search for a free block that is large enough. Automatic
    variables are usually faster (because it is just some space on the stack).
    Try to use variables on the stack as much as possible. For variables that
    take up a lot of space or that you just have to create dynamically use
    dynamic allocation.

    If it slows down your program you can always overload the new operator and
    make a smarter (and likely more wasteful considering memory) implementation.

    Regards, Ron AF Greve.

    > thanks!
    > --
    > jb
    >
    > (replace y with x if you want to reply by e-mail)
    >
    >
     
    Moonlit, Dec 7, 2003
    #2
    1. Advertising

  3. Re: Allocating memory correctly

    "Moonlit" <> wrote in message
    news:3fd31475$0$210$4all.nl...

    > > Whenever allocating memory using operator new or operator new[] I

    feel
    > > like I should only use it very sparingly, because otherwise memory is

    > wasted
    > > (by additional overhead needed to manage all those allocations) which

    also
    > > loses some performance. I am specifically talking about many little
    > > allocations (approx. 16-512 bytes). Is my feeling about this justified?
    > >

    > Typically new has to search for a free block that is large enough.

    Automatic
    > variables are usually faster (because it is just some space on the stack).
    > Try to use variables on the stack as much as possible. For variables that
    > take up a lot of space or that you just have to create dynamically use
    > dynamic allocation.


    Hi,

    in my case I cannot use automatic variables, since the allocations are
    either an array of unknown size (but at least 1 element) or the variable
    needs to live longer than automatic variables would. But since a lot of
    those allocations might be done, I am asking myself if it is necessary to
    write a memory manager myself or if using many vector's helps (not sure
    about its allocator, but I am guessing/hoping that it uses the same memory
    pool for the same kind of vectors?) or if everything is fine the way I have
    it.

    thanks
    --
    jb

    (replace y with x if you want to reply by e-mail)
     
    Jakob Bieling, Dec 7, 2003
    #3
  4. Jakob Bieling

    Moonlit Guest

    Re: Allocating memory correctly

    Hi,

    "Jakob Bieling" <> wrote in message
    news:bqv5ih$6cq$02$-online.com...
    > "Moonlit" <> wrote in message
    > news:3fd31475$0$210$4all.nl...
    >
    > > > Whenever allocating memory using operator new or operator new[] I

    > feel
    > > > like I should only use it very sparingly, because otherwise memory is

    > > wasted
    > > > (by additional overhead needed to manage all those allocations) which

    > also
    > > > loses some performance. I am specifically talking about many little
    > > > allocations (approx. 16-512 bytes). Is my feeling about this

    justified?
    > > >

    > > Typically new has to search for a free block that is large enough.

    > Automatic
    > > variables are usually faster (because it is just some space on the

    stack).
    > > Try to use variables on the stack as much as possible. For variables

    that
    > > take up a lot of space or that you just have to create dynamically use
    > > dynamic allocation.

    >
    > Hi,
    >
    > in my case I cannot use automatic variables, since the allocations are
    > either an array of unknown size (but at least 1 element) or the variable
    > needs to live longer than automatic variables would. But since a lot of
    > those allocations might be done, I am asking myself if it is necessary to
    > write a memory manager myself or if using many vector's helps (not sure


    I wouldn't start with that.

    > about its allocator, but I am guessing/hoping that it uses the same memory
    > pool for the same kind of vectors?) or if everything is fine the way I

    have
    > it.


    If I where you I would use vector<> for arrays.

    Then later on when your app actually does run too slow and an analysis of
    your code shows it is due to new/delete you might invest some time in
    overloading new/delete operator (do not release the memory for the class but
    insert it into a linked list then when a new is done return the top of the
    list).

    Regards, Ron AF Greve.

    >
    > thanks
    > --
    > jb
    >
    > (replace y with x if you want to reply by e-mail)
    >
    >
     
    Moonlit, Dec 7, 2003
    #4
  5. Jakob Bieling

    Pete Becker Guest

    Re: Allocating memory correctly

    Jakob Bieling wrote:
    >
    > in my case I cannot use automatic variables, since the allocations are
    > either an array of unknown size (but at least 1 element) or the variable
    > needs to live longer than automatic variables would.


    Those are good reasons to use the free store.

    > But since a lot of
    > those allocations might be done, I am asking myself if it is necessary to
    > write a memory manager myself


    If you can write a memory manager that's better than the one that comes
    with your compiler, by all means do it. <g> One advantage that you might
    have is that you know the details of your application's memory usage. If
    so, you might be able to do a better job for your application than the
    general-purpose memory manager that comes with your compiler. But be
    warned: memory managers are hard to write, and even harder to debug,
    because the symptoms of a bug usually show up far from the point where
    the actual error occurs.

    > or if using many vector's helps (not sure
    > about its allocator, but I am guessing/hoping that it uses the same memory
    > pool for the same kind of vectors?)


    Maybe. But don't underestimate the capabilities of the memory manager
    that comes with the compiler. They're often quite good.

    > or if everything is fine the way I have it.
    >


    If your application doesn't meet its requirements and you've determined
    that the cause is the memory manager then you have to replace the memory
    manager. If you application meets its requirements then everything is
    fine the way you have it.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Dec 7, 2003
    #5
  6. Jakob Bieling

    Dan W. Guest

    On Sun, 7 Dec 2003 12:21:31 +0100, "Jakob Bieling" <>
    wrote:

    >Hi,
    >
    > Whenever allocating memory using operator new or operator new[] I feel
    >like I should only use it very sparingly, because otherwise memory is wasted
    >(by additional overhead needed to manage all those allocations) which also
    >loses some performance. I am specifically talking about many little
    >allocations (approx. 16-512 bytes). Is my feeling about this justified?


    Yes it is. That's why the STL provides the means to substitute custom
    allocators, and often package their own allocators. Typically, they
    allocate memory in big chunks, arrays of uninitialized objects that
    can be used for more quick and efficient allocation for small objects.
    The standard allocator is notably slow performing in multithreading
    and multiprocessing situations. STLport, I hear, have a very good
    allocator.
     
    Dan W., Dec 7, 2003
    #6
  7. Re: Allocating memory correctly

    "Pete Becker" <> wrote in message
    news:...
    > Jakob Bieling wrote:
    > >
    > > in my case I cannot use automatic variables, since the allocations

    are
    > > either an array of unknown size (but at least 1 element) or the variable
    > > needs to live longer than automatic variables would.

    >
    > Those are good reasons to use the free store.
    >
    > > But since a lot of
    > > those allocations might be done, I am asking myself if it is necessary

    to
    > > write a memory manager myself

    >
    > If you can write a memory manager that's better than the one that comes
    > with your compiler, by all means do it. <g> One advantage that you might
    > have is that you know the details of your application's memory usage. If
    > so, you might be able to do a better job for your application than the
    > general-purpose memory manager that comes with your compiler. But be
    > warned: memory managers are hard to write, and even harder to debug,
    > because the symptoms of a bug usually show up far from the point where
    > the actual error occurs.
    >
    > > or if using many vector's helps (not sure
    > > about its allocator, but I am guessing/hoping that it uses the same

    memory
    > > pool for the same kind of vectors?)

    >
    > Maybe. But don't underestimate the capabilities of the memory manager
    > that comes with the compiler. They're often quite good.
    >
    > > or if everything is fine the way I have it.
    > >

    >
    > If your application doesn't meet its requirements and you've determined
    > that the cause is the memory manager then you have to replace the memory
    > manager. If you application meets its requirements then everything is
    > fine the way you have it.



    Thanks guys, I'll just use the default thingies and see how well it
    performs. :)
    --
    jb

    (replace y with x if you want to reply by e-mail)
     
    Jakob Bieling, Dec 7, 2003
    #7
  8. Jakob Bieling

    Pete Becker Guest

    "Dan W." wrote:
    >
    > STLport, I hear, have a very good
    > allocator.


    "Very good" depends on what your requirements are. The STLport allocator
    is fast, but it doesn't release memory for use by the rest of the
    application.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Dec 7, 2003
    #8
  9. Re: Allocating memory correctly

    In general, with C++, you should avoid dynamic memory allocations.
    Dynamic memory allocation should be considered only after you have
    determined that a local variable or a fixed size allocation will not
    do the job.

    Also, it might be better to use STL than direct dynamic allocations
    in your code. STL will take care of allocating and freeing memory as
    needed.

    Sandeep
    --
    http://www.EventHelix.com/EventStudio
    EventStudio 2.0 - System Architecture Design CASE Tool
     
    EventHelix.com, Dec 7, 2003
    #9
  10. Pete Becker wrote:
    > "Dan W." wrote:
    >
    >>STLport, I hear, have a very good
    >>allocator.

    >
    >
    > "Very good" depends on what your requirements are. The STLport allocator
    > is fast, but it doesn't release memory for use by the rest of the
    > application.
    >


    darn - those nasty trade-offs ... :)

    I suppose it keeps us software engineers in jobs - oh wait a sec, some
    engineers in jobs.
     
    Gianni Mariani, Dec 7, 2003
    #10
  11. Jakob Bieling

    Pete Becker Guest

    Gianni Mariani wrote:
    >
    > I suppose it keeps us software engineers in jobs - oh wait a sec, some
    > engineers in jobs.


    :-(

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Dec 7, 2003
    #11
    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. hall
    Replies:
    4
    Views:
    459
  2. soni29
    Replies:
    6
    Views:
    447
    Kevin Goodsell
    Sep 5, 2003
  3. Axel
    Replies:
    1
    Views:
    769
    stephan beal
    Oct 27, 2003
  4. filia&sofia

    Dynamically and "correctly" allocating memory

    filia&sofia, Aug 29, 2007, in forum: C Programming
    Replies:
    13
    Views:
    535
    Richard Heathfield
    Sep 1, 2007
  5. Rakesh Kumar
    Replies:
    5
    Views:
    695
    James Kanze
    Dec 21, 2007
Loading...

Share This Page