From: cpcahil@virtech.uucp (Conor P. Cahill)
Subject: Re: SUMMARY Re: Purify vs dbmalloc
Organization: Virtual Technologies Inc.
Date: Tue, 6 Oct 1992 22:19:54 GMT

This took a while to respond to because I had to gather a few facts first....

geoff@flash.bellcore.com (Geoffrey Clemm) writes:
>In article <Bv1H6r.EEx@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>	   SENTINEL accumulates all
>	   leaks from a particular location in the code and reports this as
>	   a single leak with the accumulated size as the size of the leak.
>	   A configuration parameter is available to set the threshold for
>	   leak reports. A second configuration parameter is available which
>	   disables the accumulation of leaks and reports each leak
>	   individually.
>
>	   Purify has automatic reports for leak detection and the reports 
>	   are similar to those of SENTINEL.

>Is this true ?  One of the most important features of Purify is that a
>leak is reported with a complete stack trace of the moment when that data
>area was allocated.  This information is critical for rapidly identifying
>the cause for the leak, since it is usually a routine several frames up
>the stack which should have freed the space.

Is what true?  Are you asking does SENTINEL provide the complete stack trace
of where the data was allocated, the answer is yes, if you want it.  The 
standard configuration is to get just the line of code that allocated the
data area, but you can enable the full stack context report by changing a
single run-time configuration setting (SE_SHOW_STACK).

>Also, has anyone done an overhead check on dbmalloc and SUMMARY ?
>The reported overhead of Purify is in the worst case (memory accesses
>in a tight loop) is a factor of 5.5 over the optimized C code (compared
>to a factor of 3.2 for the program compiled for debugging).
>For an "average" case (the main component of the gcc compiler),
>Purify was a factor of 2.3 slower than optimized code, the a.out size
>was 1.7 times as large, and the heap size was 1.2 times as large.

We have the following statistics based upon a program that allocates, 
reallocates and frees data in a tight loop (it keeps a table of 1,000 
allocations and randomly chooses one to free and allocate again, or 
to reallocate).  I beleive this is the worst case for both Purify and
SENTINEL because both programs must perform a stack trace at every 
malloc and free (to record where the action took place).

The test program allocates 1,000,000 data areas of varying sizes from 80
bytes to 90,000 bytes keeping 1,000 allocations alive at any point in time
and randomly selecting one of the 1,000 slots for reallocation and/or
freeing. (While the word random is used here, all invocations of the program
use the same seed and therefore generate the same random sequence of sizes
on the same system).

		SUN SPARC 2 w/ Solaris 1.0.1

			User		System		Program
			CPU		  CPU		 Size 

standard libc		 65.9		  0.4		1.54MB
Purify			169.3		 51.2		1.56MB
dbmalloc     		314.8		  0.9		4.66MB
dbmalloc no fill*	 75.5		  0.9		4.66MB
SENTINEL     		327.9		 53.2		2.54MB
SENTINEL no fill*	139.9		 50.6		2.54MB
SENTINEL no stack* 	261.0             0.6           2.51MB
SENTINEL no stack/fill*  67.0             0.6           2.51MB
SENTINEL disabled*	 56.0		  0.5		2.51MB

	
		HP 9000/847 w/ HP-UX 8.07 (with 30 users online)
	
			User		System		Memory
standard		 20.0		  0.1		0.86MB
Purify			  NA 		  NA 		NA
dbmalloc full		214.7		  0.8		1.81MB
dbmalloc no fill*	 38.1		  0.5		1.81MB
SENTINEL full		205.8		  1.1		1.38MB
SENTINEL no fill*	145.3		  2.1		1.38MB
SENTIENL no stack*	 95.3		  0.4		1.38MB
SENTINEL no stack/fill	 32.8		  0.2           1.38MB
SENTINEL disabled*	 29.8		  0.3		1.38MB


		Intel 80486 w/ Interactive UNIX 3.0**

			User 		System		Memory
standard		 21.1		  0.8		2.56MB
Purify			  NA 		  NA 		  NA 
dbmalloc full		115.3		  1.8		1.92MB
dbmalloc no fill*	 46.6		  0.8		1.92MB
SENTINEL full		168.1		  1.5		1.29MB
SENTINEL no fill*	 92.6             0.5           1.29MB
SENTINEL no stack*	139.0             2.1           1.33MB
SENTINEL no stack/fill	 64.7		  0.6           1.33MB
SENTINEL disabled*	 54.9             1.0           1.33MB

*  SENTINEL and dbmalloc provide limited action modes which give better 
   performance at the expense of some of the error checking capabilities.
   The following modes are supported:

	no fill		- data area filling is disabled.  This reduces
			  the likelyhood that small data overruns outside
			  of sentinel control will get caught and excludes
			  any uninitialized read errors.
	no stack	- do not record the stack of where allocations are
			  made and freed.  Only the stack of where the error
			  is detected will be recorded.
	disabled	- do not perform any extra error checking.

   dbmalloc only supports the "no fill" mode (other than its normal mode).
	
** the version of rand shipped with ISC UNIX generates a much smaller
   range of values than the versions on both HP-UX and Solaris.  This
   causes some of the 

NA - not available on this architecture

-----------------------------------------
PERFORMANCE TEST 2 - memory access

This test involves running the following program with each debugging
environment:

	main()
	{
		long i;
		char * t, *u;
		t = (char * ) malloc(300);
		u = (char * ) malloc(300);

		for(i=0; i < 1000000; i++)
		{
			memset(t,'\0',300);
			memset(u,'\0',300);
			memcmp(t, u, 300);
		}
	}

This program was compiled without optimization in each environment.


ENVIRONMENT	TOOL           USER CPU	  SYSTEM CPU

Sun Sparc 2:	normal cc        49.8 	    0.0
		Purify     	104.4	    0.4
		dbmalloc	359.9       0.1
		SENTINEL	114.2       0.8

HP 9000/847:	normal cc        27.4 	    0.0
		Purify     	   NA        NA
		dbmalloc	528.3       1.3
		SENTINEL	131.1       0.3

Intel 80486:	normal cc 	 89.0	    1.3
		Purify		   NA        NA
		dbmalloc	421.1       0.9
		SENTINEL	 97.8       0.8




-- 
*** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***

Conor P. Cahill              (703)430-9247            cpcahil@virtech.vti.com
Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 20166 
Newsgroups: comp.software-eng