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!
--
jb

(replace y with x if you want to reply by e-mail)

[Moonlit]

Hi,
"Jakob Bieling" <ne*****@gmy.net> wrote in message
news:bq*************@news.t-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)

[Jakob Bieling]

"Moonlit" <al******@jupiter.universe> wrote in message
news:3f*********************@news.xs4all.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)

[Moonlit]

Hi,

"Jakob Bieling" <ne*****@gmy.net> wrote in message
news:bq*************@news.t-online.com...

"Moonlit" <al******@jupiter.universe> wrote in message
news:3f*********************@news.xs4all.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)

[Pete Becker]

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)

[Jakob Bieling]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

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)

[Dan W.]

On Sun, 7 Dec 2003 12:21:31 +0100, "Jakob Bieling" <ne*****@gmy.net>
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.

[Pete Becker]

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

[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
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool

[Gianni Mariani]

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.

[Pete Becker]

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)