Q:Frequent malloc'ing and free'ing 
Author Message
 Q:Frequent malloc'ing and free'ing

I have a sort of philosophical qustion:

I have a function that has 8 large vectors (~7000 elements, double precision)  
that are required for work space. I malloc and free these every time the  
function is called, which is _very_ frequently (200k times during the course of  
the program). This function forms only part of a larger program and the work  
space is not needed at all anywhere else.

Is this really bad form? What are the issues involved in malloc'ing and  
free'ing this much memory _this often_?
I'm confident that there are no memory leaks, so how else can this practice  
handicap the program?
Should I take the malloc and free out of the function and make the work space  
extern in scope? Or maybe pass pointers to the work space to the function?

Thanks for any advice,

Thad
-----



Sat, 01 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

[...]

Quote:
>I have a function that has 8 large vectors (~7000 elements, double precision)  
>that are required for work space. I malloc and free these every time the  
>function is called, which is _very_ frequently (200k times during the course of  
>the program). This function forms only part of a larger program and the work  
>space is not needed at all anywhere else.

>Is this really bad form? What are the issues involved in malloc'ing and  
>free'ing this much memory _this often_?

It's somewhat time consuming.

Quote:
>Should I take the malloc and free out of the function and make the work space  
>extern in scope? Or maybe pass pointers to the work space to the function?

You may do this, yes. Say, allocate the memory once and free it if you are
sure you do not need it anymore. You can even use realloc() instead of malloc()
and check whether realloc() would shrink your table to skip it then. Whether
this all is possible depends on your programmes logic of course.

Bye, Juergen

--
\ Real name     : Juergen Heinzl     \       no flames      /

  \ Phone Private : +49 911-4501186    \                  /



Sat, 01 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Quote:

>I have a sort of philosophical qustion:

>I have a function that has 8 large vectors (~7000 elements, double precision)  
>that are required for work space. I malloc and free these every time the  
>function is called, which is _very_ frequently (200k times during the course of  
>the program). This function forms only part of a larger program and the work  
>space is not needed at all anywhere else.

This program takes approximately one second to run on my PC:

#include <stdlib.h>
#include <stdio.h>

int main()
{
        long i;

        for (i = 0; i < 1000000; i++) {
                void *p = malloc(10000);
                if (!p) fprintf(stderr, "Eek!\n");
                free(p);
        }
        return 0;

Quote:
}

If your program does anything besides calling malloc and free, it is
unlikely that moving the memory allocation out of the function is
going to make a noticeable difference on execution time.

By keeping memory management in your function you avoid being dependent
on the calling code doing the right thing.

Ulric
--
This is a keyboard. Cats do not walk on keyboards.



Sat, 01 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Quote:

>I have a sort of philosophical qustion:

>I have a function that has 8 large vectors (~7000 elements, double precision)
>that are required for work space. I malloc and free these every time the
>function is called, which is _very_ frequently (200k times during the course
of
>the program). This function forms only part of a larger program and the work
>space is not needed at all anywhere else.

>Is this really bad form? What are the issues involved in malloc'ing and
>free'ing this much memory _this often_?
>I'm confident that there are no memory leaks, so how else can this practice
>handicap the program?
>Should I take the malloc and free out of the function and make the work space
>extern in scope? Or maybe pass pointers to the work space to the function?

The impact of frequent malloc()/free() calls is likely rather system
dependent.  I have found on some systems, it is a very expensive operation.
On other systems, the impact is not so great.  On some of the more primitive
operating systems, memory can become so fragmented that even though large
amounts of memory are available, you cannot get any available resource.  A
solution is to write your own memory allocation routines, which allocate a
large block and then suballocate from that.  It's actually pretty easy.  If
you want to use this technique from multiple threads, you will need a critical
section or some such system dependent device.  I use a bit array as an address
list of free blocks.  When a small block is requested, do a scan to find the
first smallest hole that is large enough to put it in.
--
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software?  Algorithms?  Pubs? http://www.infoseek.com


Sat, 01 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Quote:

>I have a sort of philosophical qustion:

>I have a function that has 8 large vectors (~7000 elements, double precision)  
>that are required for work space. I malloc and free these every time the  
>function is called, which is _very_ frequently (200k times during the course of  
>the program). This function forms only part of a larger program and the work  
>space is not needed at all anywhere else.

>Is this really bad form? What are the issues involved in malloc'ing and  
>free'ing this much memory _this often_?
>I'm confident that there are no memory leaks, so how else can this practice  
>handicap the program?
>Should I take the malloc and free out of the function and make the work space  
>extern in scope? Or maybe pass pointers to the work space to the function?

malloc() and free() are not necessarily fast routines.  In any case, they
are a performance hit.  First thing to try is doing without them- can
the algorithm be reworked to not use them without a signifigant hit
in computational cost?  If they can't be eliminated, and the function
doesn't have to be reentrent (the program isn't multithreaded), make them
static- you'll have a huge permenate cost (the arrays will never be
deallocated), but you won't have the allocation/deallocation overhead.
Just as good, but a little more complex to code, would be passing them
in from the calling code.  Lift the allocation/deallocation costs up
out of the main (200K iterations) loop.  You might also try using alloca(),
which is usually (but not always) faster - but beware of blowing your
stack.

Quote:

>Thanks for any advice,

Brian


Sat, 01 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Repeated calls to malloc() and free() involving a memory block of the same
(large) size, could be very inefficient. On the other hand, it may be very
fast indeed.

It is likely to be inefficient if there are other allocations of heap memory
which are not free'd in the meantime. Imagine this sequence...

a:    p = malloc(8192) ;
        free(p) ; /* There's an 8Kb block in free store */
        malloc(4096) ; /* No 4Kb blocks in free store so break up the 8Kb
block */
        goto a ; /* ...where we will need to extend heap space */

In principle then, it's a bad idea because (although your program may
perform well at the moment) it may break (or at least, slow down) when
someone modifies it sometime in the future.

In order to avoid any potential stack limitations (you don't say which
platforms you're targetting) I would be inclined to use a static array.

--
Andy Knight (There's no X in my E-mail address)

Quote:

>I have a sort of philosophical qustion:

>I have a function that has 8 large vectors (~7000 elements, double
precision)
>that are required for work space. I malloc and free these every time the
>function is called, which is _very_ frequently (200k times during the
course of
>the program). This function forms only part of a larger program and the
work
>space is not needed at all anywhere else.

>Is this really bad form? What are the issues involved in malloc'ing and
>free'ing this much memory _this often_?
>I'm confident that there are no memory leaks, so how else can this practice
>handicap the program?
>Should I take the malloc and free out of the function and make the work
space
>extern in scope? Or maybe pass pointers to the work space to the function?

>Thanks for any advice,

>Thad
>-----




Sun, 02 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Quote:

> Repeated calls to malloc() and free() involving a memory block of the same
> (large) size, could be very inefficient. On the other hand, it may be very
> fast indeed.

> It is likely to be inefficient if there are other allocations of heap memory
> which are not free'd in the meantime. Imagine this sequence...

> a:    p = malloc(8192) ;
>         free(p) ; /* There's an 8Kb block in free store */

Not necessarily. Many memory managers merge adjacent free blocks, in
which case there's no 8k block, but one bigger one.

Quote:
>         malloc(4096) ; /* No 4Kb blocks in free store so break up the 8Kb
> block */
>         goto a ; /* ...where we will need to extend heap space */

> In principle then, it's a bad idea because (although your program may
> perform well at the moment) it may break (or at least, slow down) when
> someone modifies it sometime in the future.

No, not in principle, but perhaps in practice with some compiler. On the
other hand, the proposed solution:

Quote:

> In order to avoid any potential stack limitations (you don't say which
> platforms you're targetting) I would be inclined to use a static array.

has a significant cost as well. If you never call this function you
still pay the price of a big array which is never used. If you use
malloc you don't.
        The issue is not whether you can think up situations which might
benefit from one approach or the other. The solution is to know what
your requirements are and decide how best to satisfy them.
        -- Pete


Sun, 02 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Regarding the frequent use of malloc/free;


Quote:
>    The issue is not whether you can think up situations which might
> benefit from one approach or the other. The solution is to know what
> your requirements are and decide how best to satisfy them.
>    -- Pete


Quote:
> It's slow. You are repeating a complex operation 200K times unnecessarily.
> Otherwise, it's totally harmless.

I think that these comments get to the heart of my orginal question. I really  
have exhuasted the optimization of the program algorithmically and by profiling  
have eliminated most bottle-necks. With a workspace size that is known at  
execution time, and pretty good memory management (With NextStep 3.3, gcc  
2.7.2, 233 PII, 64 MB, the virtual memory size remains constant over two days  
of simulation.), I guess that the frequent malloc/free calls are just  
uneccesary.


        for (i = 0; i < 1000000; i++) {
                void *p = malloc(10000);
                if (!p) fprintf(stderr, "Eek!\n");
                free(p);
        }
only takes two seconds to execute means the overhead is negligible (probably  
since the size never changes?), then as Ulrich put's it:

Quote:
> By keeping memory management in your function you avoid being dependent
> on the calling code doing the right thing.

Also, the function becomes very portable, which I like the idea of. I think  
I've got some other uses for it.

Thanks for the replys, it's set my mind at ease.

Thad
------



Sun, 02 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Thad Harroun wrote in a message to All:

 TH> I have a function that has 8 large vectors (~7000 elements, double
 TH> precision) that are required for work space. I malloc and free
 TH> these every time the function is called, which is _very_
 TH> frequently
 TH> (200k times during the course of the program). This function forms
 TH> only part of a larger program and the work space is not needed at
 TH> all anywhere else.

I would definitely use some sort of initialize() function which
allocates the required memory once and stores the pointer in a static
variable, and also registers a deinitialize() function that will
release the memory upon exit. malloc() can be slow enough to justify
this, especially if your function is going to be called 200000 times.

greetings,
Tom



Sun, 02 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing


Quote:

>I would definitely use some sort of initialize() function which
>allocates the required memory once and stores the pointer in a static
>variable, and also registers a deinitialize() function that will
>release the memory upon exit. malloc() can be slow enough to justify
>this, especially if your function is going to be called 200000 times.

In a multiuser, multitasking environment it is bad use of resources
to allocate all the memory a program will possibly use at once.
Whether it is justified or not depends on such things as how much
memory is allocated, how long it is used, where the decision on
how much memory is needed can best be done, and last but not least
how much time is actually spent in malloc.

My old Atari had a malloc which would self destruct after it had
been called enough times. It wouldn't even survive 200000 calls,
so performance would be a non-issue.

Ulric
--
This is a keyboard. Cats do not walk on keyboards.



Mon, 03 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Ulric Eriksson wrote in a message to Tom Torfs:

Quote:
>I would definitely use some sort of initialize() function which
>allocates the required memory once and stores the pointer in a static
>variable, and also registers a deinitialize() function that will
>release the memory upon exit. malloc() can be slow enough to justify
>this, especially if your function is going to be called 200000 times.

 UE> In a multiuser, multitasking environment it is bad use of
 UE> resources
 UE> to allocate all the memory a program will possibly use at once.

Really? In his case the alternative would be to ask the operating
system at least 200000 times during the execution of the program to
allocate and subsequently free the memory again. I'd think that would
put a greater load on the system than just one malloc() before the
memory is needed and one free() afterwards.

 UE> Whether it is justified or not depends on such things as how much
 UE> memory is allocated, how long it is used, where the decision on
 UE> how
 UE> much memory is needed can best be done, and last but not least how
 UE> much time is actually spent in malloc.

Of course.

 UE> My old Atari had a malloc which would self destruct after it had
 UE> been called enough times. It wouldn't even survive 200000 calls,
 UE> so
 UE> performance would be a non-issue.

Did it use a static array to keep track of memory blocks or so ? One
would think compiler writers would have a little more common sense than
that...

greetings,
Tom



Mon, 03 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

--
Andy Knight (There's no X in my E-mail address)

Quote:


>> Repeated calls to malloc() and free() involving a memory block of the
same
>> (large) size, could be very inefficient. On the other hand, it may be
very
>> fast indeed.

>> It is likely to be inefficient if there are other allocations of heap
memory
>> which are not free'd in the meantime. Imagine this sequence...

>> a:    p = malloc(8192) ;
>>         free(p) ; /* There's an 8Kb block in free store */

>Not necessarily. Many memory managers merge adjacent free blocks, in
>which case there's no 8k block, but one bigger one.

Ok - I'll change the comment to... /* There's at least one 8Kb block in free
store */

Quote:
>>         malloc(4096) ; /* No 4Kb blocks in free store so break up the 8Kb
>> block */
>>         goto a ; /* ...where we will need to extend heap space */

>> In principle then, it's a bad idea because (although your program may
>> perform well at the moment) it may break (or at least, slow down) when
>> someone modifies it sometime in the future.

>No, not in principle, but perhaps in practice with some compiler. On the
>other hand, the proposed solution:

This behaviour has nothing at all to do with the compiler.

Quote:

>> In order to avoid any potential stack limitations (you don't say which
>> platforms you're targetting) I would be inclined to use a static array.

>has a significant cost as well. If you never call this function you
>still pay the price of a big array which is never used. If you use
>malloc you don't.

What is this significant cost? The issue here is one of performance. If you
can avoid a multitude of calls to malloc/free by setting aside a fixed
amount of memory (albeit that it may never be used) this is surely cheaper
in the long run. Perhaps the best solution is to malloc just once and
register an atexit function to handle the free'ing (if you're that way
inclined!!)

Quote:
> The issue is not whether you can think up situations which might
>benefit from one approach or the other. The solution is to know what
>your requirements are and decide how best to satisfy them.

Indeed, but the question was quite specific.


Tue, 04 Jul 2000 03:00:00 GMT  
 Q:Frequent malloc'ing and free'ing

Quote:

> --


> >> Repeated calls to malloc() and free() involving a memory block of the
> same
> >> (large) size, could be very inefficient. On the other hand, it may be
> very
> >> fast indeed.

> >> In principle then, it's a bad idea because (although your program may
> >> perform well at the moment) it may break (or at least, slow down) when
> >> someone modifies it sometime in the future.

> >No, not in principle, but perhaps in practice with some compiler. On the
> >other hand, the proposed solution:

> This behaviour has nothing at all to do with the compiler.

I'm not sure if you're making an overly technical distinction between
the compiler and the runtime library, or are missing the point. The
compilation system imposes a memory management scheme that your
application lives within. The performance of the application often
depends on the details of that underlying memory management scheme, and
blanket statements about which blocks are where after certain operations
are simply meaningless without taking into account the details of that
memory management scheme.

Quote:

> >> In order to avoid any potential stack limitations (you don't say which
> >> platforms you're targetting) I would be inclined to use a static array.

> >has a significant cost as well. If you never call this function you
> >still pay the price of a big array which is never used. If you use
> >malloc you don't.

> What is this significant cost?

The cost is that you have an 8k block that is not available for use by
any other part of your application, or by any other application that may
be running on the system. If you want an example, consider the usual DOS
small model memory layout: one 64K segment for all data, including
static, stack, and heap. If you permanently set aside 8k in a static
block you have 8k less heap space available (often evidenced by a crash
as the stack runs into the heap).

Quote:
> The issue here is one of performance.

If your program crashes because it ran out of memory, how good is its
performance?

Quote:
> If you
> can avoid a multitude of calls to malloc/free by setting aside a fixed
> amount of memory (albeit that it may never be used) this is surely cheaper
> in the long run.

Not if doing that means that some other attempted allocation fails
because you're reserving memory that you don't need.

 > Perhaps the best solution is to malloc just once and
 > register an atexit function to handle the free'ing (if you're that
way
 > inclined!!)
 >
 > > The issue is not whether you can think up situations which might
 > >benefit from one approach or the other. The solution is to know what
 > >your requirements are and decide how best to satisfy them.
 >
 > Indeed, but the question was quite specific.

Yes, the question was specific, but the answer depends on context, which
was not presented. Without knowing how the application uses memory and
what constraints the environment places on memory usage it is impossible
to give a short, definitive answer to the question.
        -- Pete



Tue, 04 Jul 2000 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Quickie on free()'ing malloc()'d mem

2. how to prevent 'free'-ing memory twice

3. malloc'ing space and converting it to a multidimensioned array

4. malloc'ing 2d array in structure

5. BUFSIZ / malloc'ing

6. Malloc() 'ing 2-D Arrays?

7. malloc()'ing struct to struct and comparison

8. malloc'ing from a function

9. malloc'ing a struct

10. malloc'ing multidimensional arrays

11. malloc'ing 1.5MB of memory

12. malloc'ing space and converting it to a multidimensioned array

 

 
Powered by phpBB® Forum Software