Suballocator?

Discussion in 'C++' started by none, Apr 27, 2011.

  1. none

    none Guest

    Sorry if this is a FAQ, I searched and found nothing.

    I have a rather large application that deals with lots and lots of this one
    particular object type. The object is always a fixed size and contains no
    pointers to external data (no heap allocations). It's basically just a
    dumb block of memory, mabye 2 KB in size. In fact, it doesn't even have
    any methods -- it's just a big block of state.

    These objects are used ubiquitously throughout the application, and in
    hundreds of functions, they are just declared right on the stack as local
    variables.

    I'm just wondering if this is inefficient. 2KB isn't huge by todays
    standards, but it's large compared to an "int" or a "float." Should I be
    using some sort of custom memory sub-allocator to deal with these, instead
    of just declaring them as locals?

    Thanks.
     
    none, Apr 27, 2011
    #1
    1. Advertising

  2. none

    none Guest

    Leigh Johnston wrote:

    > If you are asking if allocating them on the free store will be faster
    > than allocating them on the stack (assuming the same number of
    > allocations) then the answer will probably be no: stack allocation
    > tends to be the fastest form of allocation mainly due to its simple
    > LIFO nature.
    >
    > /Leigh


    Good point. I guess my thought was that in most cases, I'd be able to
    avoid any allocation, stack or otherwise. I'd just have a global "pool" of
    them and some kind of smart pointer to keep track of which blocks are "in
    use" and which ones are free. The overhead of the manager itself would
    probably outweigh the benefit.
     
    none, Apr 27, 2011
    #2
    1. Advertising

  3. none

    Marc Guest

    Leigh Johnston wrote:

    > On 27/04/2011 20:53, none wrote:

    [...]
    >> I'm just wondering if this is inefficient. 2KB isn't huge by todays
    >> standards, but it's large compared to an "int" or a "float." Should I be
    >> using some sort of custom memory sub-allocator to deal with these, instead
    >> of just declaring them as locals?

    >
    > If you are asking if allocating them on the free store will be faster
    > than allocating them on the stack (assuming the same number of
    > allocations) then the answer will probably be no: stack allocation tends
    > to be the fastest form of allocation mainly due to its simple LIFO nature.


    I don't believe the goal is to speed up the allocation. The goal is to
    avoid bloating the stack, which could help improve cache behaviours
    for instance. And he could get allocations as fast as those on the
    stack by implementing a stack in a block of memory preallocated from
    the heap.

    Now this is unlikely to be worth the trouble, but you never know...
     
    Marc, Apr 27, 2011
    #3
  4. none

    MikeWhy Guest

    "none" <> wrote in message
    news:Xns9ED48F8D380C4nonenonenone@69.16.186.52...
    > Leigh Johnston wrote:
    >
    >> If you are asking if allocating them on the free store will be faster
    >> than allocating them on the stack (assuming the same number of
    >> allocations) then the answer will probably be no: stack allocation
    >> tends to be the fastest form of allocation mainly due to its simple
    >> LIFO nature.
    >>
    >> /Leigh

    >
    > Good point. I guess my thought was that in most cases, I'd be able to
    > avoid any allocation, stack or otherwise. I'd just have a global "pool"
    > of
    > them and some kind of smart pointer to keep track of which blocks are "in
    > use" and which ones are free. The overhead of the manager itself would
    > probably outweigh the benefit.


    I would think stack allocation beats them all, since there is no allocation
    as such. This gets into system specific behavior. In general, the function
    preamble increments the stack pointer to allow room for all the locals in
    one fell swoop. Locals are then carved from fixed offsets in this space,
    essentially sub-allocating them at compile time.
     
    MikeWhy, Apr 27, 2011
    #4
  5. none

    Marc Guest

    Leigh Johnston wrote:

    > The overhead of not using a simple LIFO allocation scheme
    > might also negate any potential savings elsewhere.


    Er, my point was: for those variables that he currently allocates on
    the stack, he could still use a LIFO (=stack) scheme (so he wouldn't
    have any overhead in the number of operations), but stored separately
    from the normal stack.
     
    Marc, Apr 27, 2011
    #5
  6. none

    Paul Guest

    "none" <> wrote in message
    news:Xns9ED48D42F2014nonenonenone@69.16.186.52...
    > Sorry if this is a FAQ, I searched and found nothing.
    >
    > I have a rather large application that deals with lots and lots of this
    > one
    > particular object type. The object is always a fixed size and contains no
    > pointers to external data (no heap allocations). It's basically just a
    > dumb block of memory, mabye 2 KB in size. In fact, it doesn't even have
    > any methods -- it's just a big block of state.
    >
    > These objects are used ubiquitously throughout the application, and in
    > hundreds of functions, they are just declared right on the stack as local
    > variables.

    I presume you mean stack segment here, not a function stack frame.

    >
    > I'm just wondering if this is inefficient. 2KB isn't huge by todays
    > standards, but it's large compared to an "int" or a "float." Should I be
    > using some sort of custom memory sub-allocator to deal with these, instead
    > of just declaring them as locals?
    >

    Whether the objects should be allocated on stack or heap depends on whether
    or not the memory resources are reclaimable at some point.
    The question is whether or not you are passing by value, or passing by
    reference/pointer.
     
    Paul, Apr 28, 2011
    #6
  7. none

    Jorgen Grahn Guest

    On Wed, 2011-04-27, none wrote:
    > Sorry if this is a FAQ, I searched and found nothing.
    >
    > I have a rather large application that deals with lots and lots of this one
    > particular object type.

    [...]
    > These objects are used ubiquitously throughout the application, and in
    > hundreds of functions, they are just declared right on the stack as local
    > variables.


    Your "lots and lots" statement at the top is a bit misleading, because
    it sounds to me as if only one or a handful exist at any given time.

    Your data cache would probably be happier with a smaller stack (and
    some systems[1] still have just a few kilobytes of stack) but I
    normally wouldn't worry about it.

    /Jorgen
    [1] The Linux kernel, some embedded systems ...

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Apr 28, 2011
    #7
    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.

Share This Page