Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Nov 1997 06:59:31 -0800 (PST)
From:      Mika Nystroem <mika@cs.caltech.edu>
To:        FreeBSD-gnats-submit@FreeBSD.ORG
Subject:   bin/5043: malloc/realloc/free (unacceptably) dog-slow on FreeBSD-3.0
Message-ID:  <199711141459.GAA13129@obelix.cs.caltech.edu>
Resent-Message-ID: <199711141500.HAA04877@hub.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         5043
>Category:       bin
>Synopsis:       malloc/realloc/free (unacceptably) dog-slow on FreeBSD-3.0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 14 07:00:01 PST 1997
>Last-Modified:
>Originator:     Mika Nystroem
>Organization:
	Department of Computer Science
	California Institute of Technology
>Release:        FreeBSD 3.0-CURRENT i386
>Environment:

FreeBSD-current-3.0/SMP, dual processor Pentium Pro 200 MHz.
Little other system activity.

>Description:
malloc and free are S-L-O-W for reasonably large memory allocations.
In an otherwise unmodified environment, the program


#include <stdlib.h>
main()
{
  int i=0;
  char *x=NULL;
  x=malloc(1000);
  while(i++<1000000) {
	x=realloc(x,500);
	x=realloc(x,1000);
  }
}

takes 
(80)vitalstatistix:/ufs/work10/test>time a.out
4.171u 62.224s 1:12.21 91.9%    3+125k 0+0io 0pf+0w

to run---almost all this time is spent in madvise() (called from 
ifree(), so it's in the free part, not the allocation part of the
code...)  This can be helped with setenv MALLOC_OPTIONS "h", 
after which the timings are

(78)vitalstatistix:/ufs/work10/test>time a.out
10.536u 0.039s 0:10.91 96.7%    1+37k 0+0io 1pf+0w

for the same program!

On a similar NetBSD/i386 system, the same program has timings

(82)varese:/ufs/work10/test>time a.out

4.403u 0.019s 0:04.44 99.3% 0+0k 0+0io 52pf+0w

(all these timings are from unprofiled, unoptimized code)

This problem surfaced on a real application that was using a lot of
realloc calls in parsing routines.

>How-To-Repeat:

	see above
>Fix:
	
	either make MALLOC_OPTIONS "h" the default, or at very least make
the implementation more clever about it.  Or use the NetBSD malloc package
instead.
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711141459.GAA13129>