head	1.2;
access;
symbols;
locks; strict;
comment	@# @;


1.2
date	2001.04.05.16.17.12;	author sobomax;	state dead;
branches;
next	1.1;

1.1
date	2001.04.05.15.17.33;	author sobomax;	state Exp;
branches;
next	;


desc
@@


1.2
log
@Rollback dlmalloc. I overlooked that it already exists under another name.

Poked by: 	roberto
@
text
@This is drop-in replacement for the standard libc malloc/realloc/free routines.
In many cases it makes a sense to use it with your program instead of the
standard ones, as sometimes it is significantly more efficient and fast,
especially for the memory intensive apps such as virtual machines, GUIs etc.
There are two methods of linking it with your program:

1) Run-time linking using LD_PRELOAD.

 This method doesn't requre to recompile a program, but doesn't work for
 statically linked binaries. Just set the following environment variable and
 run your program - dynamic linker will automatically do the rest:

 LD_PRELOAD=%%PREFIX%%/lib/dlmalloc_module.so

2) Compile-time linking.

 Compile your applications that use the dlmalloc port with the following
 command line options:

 -I%%PREFIX%%/include/dlmalloc -L%%PREFIX%%/lib -ldlmalloc

 Note that the include (-I<path>) directive shown here should appear before
 any other include directive that would cause the compiler to find the FreeBSD
 file malloc.h. Using the FreeBSD malloc.h instead of the dlmalloc malloc.h
 will result in an app that fails in many odd and maybe spectacular ways.


It makes a sense to use the first method to benchmark effect of using this
version of memory management routines and if positive effect is confirmed then
recompile the application using the second method.
@


1.1
log
@Add dlmalloc 2.7.0, a very efficient malloc/free/realloc implementation.

According to my tests it is *amazingly* efficient - it gave me about 10%
memory saving (SIZE in the top(1)) for the large processes like X and jre
without any measureable performance saturation.

Moreover, due to not very clear for me reasons Python benchmark (pybench)
is about 60% (!!!) faster with this allocator comparing to the libc one.
Obviously we should investigate this further and if there is no error
then tune either Python or our own malloc.

Alternatively we may evaluate a possibility to make it (or part of it) our
default malloc(), because it is friendly licensed and actively maintained.
@
text
@@
