In message <[EMAIL PROTECTED]>, David Schultz writes: >Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: >> In message <[EMAIL PROTECTED]>, David Schultz writes: >> >> >You can find a somewhat more thorough comparison of malloc >> >implementations at http://citeseer.nj.nec.com/440671.html . >> >> There are many problems with this paper, and my feeling is that it was >> written with a very specific purpose in mind, although I havn't been >> able to figure out just what that purpose was. > >I did say `somewhat', didn't I? ;-) As I mentioned in the part of >my message that you didn't quote, I don't much care for the paper >either, but it's the only half-reasonable comparison I know of. >I don't think the authors know what they're talking about, but they >did collect extensive data for some real world programs, which I >assume is valid.
Right, and their study of the correlation between number of bugs on the windshield versus price-tag is scientifically rigorous and highly commendable. You just can't conclude anything useful from it :-) >I agree that the behavior of the program from the point of view of >the VM system is the most important metric. But internal and >external fragmentation are also significant issues. Often, these >are a result of programmers not understanding how their malloc >works. For example, programs that make numerous 2K allocations in >phkmalloc will get twice the amount of memory they asked for, and >since each chunk is page-aligned, it will be twice as bad for the >VM system. Not if they are 2k allocations, but if they are 2k+1 allocations: yes. >A harder problem to solve is fragmentation for long-running >servers, where the RSS tends to creep upwards over time as virtual >memory fills with holes. This is where you want to run phkmalloc with the 'H' option. It practically makes it a non-issue last I tried. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
