malloc
Momchil Velikov
velco@fadata.bg
Mon Sep 10 01:43:00 GMT 2001
>>>>> "blackdragon" == blackdragon <blackdragon@tyler.net> writes:
blackdragon> <OPINION>
[...]
blackdragon> for the latter, however... in most cases the effect is not noticeable,
blackdragon> but in large apps, or those that use large amounts of dynamic memory
blackdragon> (such as to implement hash tables) it would generally be preferable to
blackdragon> have a fast allocator rather than a space-effecient one. memory is cheap
blackdragon> and available; time is not.
blackdragon> </OPINION>
Well, this may not by quite true, increased memory usage can result on
increased pressure on the cache, the TLBs, and more paging activity.
blackdragon> it is my intention (given the nature of what i want to know as well as
blackdragon> my decidely non-godly knowledge of computing) to keep the tests simple
blackdragon> and fair, and mostly involve repeatedly allocating little blocks of
blackdragon> memory and then freeing them; this should (i hope) magnify what i wish
blackdragon> to compare. i will, however, also work on larger and more complex data
blackdragon> types commonly used, such as linked lists.
Note that random malloc/free combinations are generally not a good
test for the performance of an allocator. The real programs exhibit
several patterns of behavior[1] and even simple allocators account for
this nowdays. A good way to measure an allocator would be to record
the sequence of malloc/free invocations made by several real programs
and than running that sequence. You may wish to look at the Phong Vo's
vmalloc, which is able to emit such a sequence.
Regards,
-velco
[1] Like the tendency for the recently allocated objects to be freed
in the near future, or the tendency the lifetime of the objects to
correlate with their size.
More information about the Libc-alpha
mailing list