From mika@obelix.cs.caltech.edu  Fri Nov 14 06:59:46 1997
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA04827
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 14 Nov 1997 06:59:45 -0800 (PST)
          (envelope-from mika@obelix.cs.caltech.edu)
Received: from obelix.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA13705; Fri, 14 Nov 97 06:59:42 PST
Received: (from mika@localhost)
	by obelix.cs.caltech.edu (8.8.8/8.8.7) id GAA13129;
	Fri, 14 Nov 1997 06:59:31 -0800 (PST)
Message-Id: <199711141459.GAA13129@obelix.cs.caltech.edu>
Date: Fri, 14 Nov 1997 06:59:31 -0800 (PST)
From: Mika Nystroem <mika@cs.caltech.edu>
Reply-To: mika@cs.caltech.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: malloc/realloc/free (unacceptably) dog-slow on FreeBSD-3.0
X-Send-Pr-Version: 3.2

>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:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 14 07:00:01 PST 1997
>Closed-Date:    Mon Apr 6 00:06:47 PDT 1998
>Last-Modified:  Fri May  8 12:50:01 PDT 1998
>Originator:     Mika Nystroem
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
	Department of Computer Science
	California Institute of Technology
>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.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Mon Apr 6 00:06:47 PDT 1998 
State-Changed-Why:  
malloc/realloc/free seems to be acceptably fast in real applications, as 
opposed to programs which doesn't do anything.  If you have a real world 
application which is slower than you think it should be, please run it 
MALLOC_OPTIONS=U and trace it with "ktrace -t u" and forward the results. 

From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: Mika Nystrom <mika@cs.caltech.edu>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/5043 
Date: Fri, 08 May 1998 21:42:06 +0200

 >Ok, we now have a real application (it is a program that compiles
 >CMOS circuits into a simulator format) that exhibits really noticeable
 >slowness on free().  This is the output of kdump (I apologize for the
 >size of this file, but I am not the person developing the code in 
 >question):
 
 Ok. got it and I have have looked at it, I can see that most of the 
 memory goes into one 8Mb and one 256k chunk, but apart from that it
 looks pretty normal to me.
 
 I don't see any reason why the madvice() call should do much difference
 in the case you sent me the data for, it would only be called about
 20 times or so in total...
 
 Was this a very simple case you ran ?  If so, please run a "normal-sized"
 case, and just upload the gzip'ed ktrace.out file for me, don't waste your
 time running kdump on it.
 
 --
 Poul-Henning Kamp             FreeBSD coreteam member
 phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
 "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal
>Unformatted:
