|
From: Mark S. <ms...@cl...> - 2005-05-19 19:59:45
|
This C program:
#include <stdlib.h>
int main(int argc, char **argv)
{
char *data =3D NULL;
int len =3D 0;
for(int i=3D0; i<2000; i++) {
len +=3D 4096;
data =3D (char *) realloc(data, len*sizeof(char));
}
free(data);
return 0;
}
Seems to cause valgrind to allocate a *lot* of memory, at least 700MB. I
tested it on a fairly stock RH9 system with gcc 3.2.2 and a fairly stock
SuSE 9.1 system with gcc 3.3.3.
Any idea why it's so inefficent?
--Mark
|
|
From: Thomas S. <ste...@gm...> - 2005-05-19 20:29:09
|
On 5/19/05, Mark Stemm <ms...@cl...> wrote: > This C program: ... > Seems to cause valgrind to allocate a *lot* of memory,=20 If you look at the realloc function in memcheck, you will find this is by design. Realloc always returns a fresh piece of address space, so that it can check for any old pointer that are not updated. Of course this uses a lot of address space, which means it uses a lot of memory. Efficiency is not the first priority for valgrind, but finding bugs in your code (which means always assuming the worst case) is. Thomas |
|
From: Nicholas N. <nj...@cs...> - 2005-05-19 21:15:38
|
On Thu, 19 May 2005, Thomas Steffen wrote: > If you look at the realloc function in memcheck, you will find this is > by design. Realloc always returns a fresh piece of address space, so > that it can check for any old pointer that are not updated. Of course > this uses a lot of address space, which means it uses a lot of memory. Are you sure? It looks to me like it reuses the same memory if the new size is smaller or equal to the old size. It allocates new memory if the new size is bigger. But the allocator does avoid recycling freed blocks for a while, which might explain the 700MB figure. N |