|
From: Howard C. <hy...@sy...> - 2007-11-14 16:06:11
|
Tom Hughes wrote: > In message <473...@ak...> > William Schauweker <wsc...@ak...> wrote: >> My suspicion is that it is the standard library allocator holding onto >> blocks of memory for reuse. > > It could be the standard C++ library hanging on to it, but that > should show up in valgrind. More likely it is glibc hanging on to > it as malloc/free don't normally return freed memory to the system. Actually, blocks larger than a certain size are usually returned to the system. The default threshold in glibc 2.5 is 128K; malloc requests of this size or larger are satisfied using mmap() and the mmap'd regions are unmapped when freed. By the way, tuning this threshold can have a noticeable impact on the degree of fragmentation in the heap, and can help malloc's performance on some workloads. http://sourceware.org/ml/libc-alpha/2006-03/msg00033.html The tests I reported here http://highlandsun.com/hyc/malloc/ all used the default glibc settings. glibc may have fared better in these tests if I had used a larger threshold but I haven't had time to re-test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ |