Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Suballocator?

Reply
Thread Tools

Suballocator?

 
 
none
Guest
Posts: n/a
 
      04-27-2011
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.
 
Reply With Quote
 
 
 
 
none
Guest
Posts: n/a
 
      04-27-2011
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.

 
Reply With Quote
 
 
 
 
Marc
Guest
Posts: n/a
 
      04-27-2011
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...
 
Reply With Quote
 
MikeWhy
Guest
Posts: n/a
 
      04-27-2011
"none" <(E-Mail Removed)> 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.

 
Reply With Quote
 
Marc
Guest
Posts: n/a
 
      04-27-2011
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.
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      04-27-2011

"none" <(E-Mail Removed)> 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.

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      04-28-2011
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 .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments