This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: malloc


>>>>> "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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]