Suballocator?

[none]

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]

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.

 

[Marc]

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

 

[MikeWhy]

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.

 

[Marc]

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.

 

[Paul]

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.

 

[Jorgen Grahn]

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