Q: Allocating memory correctly

[Jakob Bieling]

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!

 

[Moonlit]

Hi,

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.

 

[Jakob Bieling]

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

 

[Moonlit]

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.

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.

 

[Pete Becker]

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.

 

[Dan W.]

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.

 

[Jakob Bieling]

Those are good reasons to use the free store.


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.


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


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.

 

[Pete Becker]

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.

 

[EventHelix.com]

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

 

[Gianni Mariani]

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

 

[Pete Becker]

I suppose it keeps us software engineers in jobs - oh wait a sec, some
engineers in jobs.

:-(