[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: better malloc strategies
Howard Chu wrote:
And another oops. The single-thread numbers for glibc in this post were
mis-copied (note they're identical to hoard's numbers). The multi-thread
numbers and the CPU times are all correct.
The actual single-thread stats for glibc in that test run were:
Still no idea why there are such erratic jumps in its behavior.
Found the explanation for this
http://sourceware.org/ml/libc-alpha/2006-03/msg00033.html
Running the glibc test with MALLOC_MMAP_THRESHOLD_ env var set to 8MB
drastically improved its performance. Aside from some high startup overhead,
it's very nearly the fastest in single-threaded, which is more in line with
what other folks have written about it. Still the slowest for multi-threaded
though.
glibc hoard umem tmalloc
size time size time size time size time
start 649 655 653 660
single 1278 01:01.95 1708 00:20.23 1693 00:22.33 1353 00:20.91
single 1278 00:26.69 1747 00:11.73 1731 00:12.37 1374 00:12.26
single 1389 00:11.33 1747 00:11.09 1736 00:11.75 1374 00:11.58
single 1412 00:11.12 1748 00:11.06 1736 00:11.71 1374 00:11.58
single 1412 00:11.09 1748 00:11.05 1736 00:11.62 1374 00:11.57
single 1408 00:11.12 1748 00:11.07 1736 00:11.65 1374 00:11.58
single 1412 00:11.11 1748 00:11.06 1736 00:11.54 1374 00:11.56
single 1402 00:11.11 1748 00:11.07 1736 00:11.51 1374 00:11.52
four 1504 00:27.48 1801 00:19.37 1786 00:19.44 1435 00:19.64
four 1502 00:24.24 1801 00:19.22 1799 00:20.90 1451 00:20.44
four 1501 00:23.67 1829 00:19.18 1807 00:19.41 1451 00:19.89
four 1497 00:23.47 1832 00:21.12 1821 00:19.84 1451 00:19.92
four 1498 00:23.68 1832 00:19.50 1821 00:21.27 1451 00:19.91
four 1498 00:23.71 1832 00:19.35 1821 00:19.63 1451 00:19.97
four 1512 00:23.71 1832 00:19.40 1821 00:19.36 1451 00:19.88
four 1512 00:24.53 1832 00:19.51 1821 00:19.59 1451 00:19.98
CPU1 02:36.32 01:38.54 01:45.14 01:42.62
CPU final 06:36.88 05:01.90 05:11.78 05:02.91
This is with current back-bdb (HEAD as of yesterday), slightly faster overall
than the January 1 code. It still looks like a tradeoff between hoard for
best speed bs tcmalloc for best memory efficiency.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/