> Yes, I verified that.
>
> > I guess I can try
> > to do some profiling since this problem did not show on Firefox (that i
> > find odd given that Firefox is just about half of the size).
>
> Yep, I'm also surprised about it.
>
> > Perhaps glibc has some stupid limit in realloc that makes it to behave
> > in a silly way for very large arrays?
>
> Dunno :P
Seems like glibc issue. On my debian testing box:
hubicka@lomikamen-jh:~$ cat t.c
#include <stdlib.h>
main(int argc, char **argv)
{
char *a = malloc (1);
int i,n=atoi(argv[1]);
for (i=2;i<n;i++)
a = realloc (a,i);
}
hubicka@lomikamen-jh:~$ time ./a.out 1000000000
real 0m10.057s
user 0m9.696s
sys 0m0.356s
And kunlun (which is a lot faster than my 2013 buldozer):
abuild@kunlun:~> time ./a.out 1000000000
real 0m59.808s
user 0m58.703s
sys 0m1.080s
GDB stops at:
(gdb) bt
#0 0x00007ffff7e70bfe in realloc () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00005555555550bf in main ()
on debian while:
(gdb) bt
#0 0x00007ffff7e7d6d0 in mem2mem_check () from /lib64/libc.so.6
#1 0x00007ffff7e81c7d in realloc_check () from /lib64/libc.so.6
#2 0x00005555555550bf in main ()
on kunlun.
Perhaps someone enabled some cool security harnessing feature without
much of benchmarking :) (but even debian numbers seems like they can be
improved)
Honza
>
> Martin
>
> >
> > Honza
> > >
> > > Martin
>
