Zdenek Salvet <salvet@ics.muni.cz> writes:

> Have you tried to measure some non-artificial benchmark like "make build" ?
> AFAIK, NetBSD malloc is heavily optimized for small allocations,
> I remeber it had beaten GNUmalloc by large margin when I did tests
> with my malloc-intensive application some time ago.

Running 4 make builds on my laptoy gave:

2:51 (first run of a new build, NetBSD malloc)
2:42 (second run, still NetBSD malloc)
2:48 (first run after adding FreeBSD's malloc to libc)
2:44 (second run, whole system using FreeBSD's malloc now)

I manually ran a "make clean" between each build.

There are two problems with using FreeBSD's malloc:

	(1) It uses mmap() which isn't counted against a process's
            virtual space.  It probably should be, no?

	(2) There are a few minor controls that we need to adjust
            per-arch.  They are pretty clearly indicated near the top
            of the file, and seem to be adjustments page allocations
            and on minimum allocations.  It's just a matter of testing
            the malloc on various ports.

There are many benefits:

	(1) A memory hungry application of mine (raytracer) will
            actually run on my smaller computer now.  NetBSD's malloc
            is pretty wasteful.

	(2) Even while the computer was paging like mad, the overall
            feel wasn't severely impacted.  Perhaps this was just
            luck, and perhaps it was due to other kernel changes, but
            the machine _felt_ nice, just slightly sluggish when I
            changed what I was doing.

	(3) By replacing malloc, we fix a long-standing bug in
            NetBSD's malloc, where it seems to throw away a page for
            every one allocated.  Try a loop of page-size allocations,
            and you'll lose 2 pages per malloc() it seems.  bind8
            added an internal memory allocator to work around just
            this problem.

All in all, I think it's time to replace our malloc with FreeBSD's
version.

--Michael