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


>Andreas Jaeger writes:
>The malloc in glibc is not slow.  It has a number of features:
>- thread safe
>- allows debugging
>- has internal checks

and

>Wolfram Gloger writes:
>All true, but you forgot the most important feature:
>- extremely memory-efficient, i.e. low fragmentation

<OPINION>
as for the first points, most OS c libraries should support all three of
these, though not perhaps to the extent that the GNU version does. while
im collecting mallocs, i will soon find out whether my assumption is
true or not. in addition, i have confirmed that the perl malloc is
indeed thread safe. i will study it more closely, along with others,
over time.

for the latter, however... in most cases the effect is not noticeable,
but in large apps, or those that use large amounts of dynamic memory
(such as to implement hash tables) it would generally be preferable to
have a fast allocator rather than a space-effecient one. memory is cheap
and available; time is not.
</OPINION>

it is my intention (given the nature of what i want to know as well as
my decidely non-godly knowledge of computing) to keep the tests simple
and fair, and mostly involve repeatedly allocating little blocks of
memory and then freeing them; this should (i hope) magnify what i wish
to compare. i will, however, also work on larger and more complex data
types commonly used, such as linked lists.

any and all criticism would be welcome.


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