Re: Performance of the Darwin 6.6 Libc malloc()

• Subject: Re: Performance of the Darwin 6.6 Libc malloc()
• From: Nat! <email@hidden>
• Date: Sat, 28 Jun 2003 11:12:48 +0200

Date: Sat, 28 Jun 2003 02:47:22 +0200
Subject: Re: Performance of the Darwin 6.6 Libc malloc()
From: Nat! <email@hidden>
To: email@hidden

are these graphs supposed to mean, that the more memory is allocated,
the faster the allocation happens ? That'd be one funny malloc. Also
how come the allocation unit size is something like between 100000
bytes and 7e+07, ain't that enormous allocation units ? That doesn't
sound right to me. If its right, who cares how fast that is ? You
usually allocate that big blocks once or twice during the lifetime of
the program. :)

The graph is not Time vs. Size, as your first question implies. Vertical
value is a rate. The data to compute a Time vs. Size graph is provided in
the Logs should that be an interest.

The graph shows that as the allocation size increases, the rate of memory
allocation increases. For a "normal" malloc implementation, we might
expect a performance curve to be rather flat; allocating in chuncks twice
as large should cause a rate increase of approximately 2x. Both of the
linux curves are very close to that shape.

Examples might include window managers, 2d
graphics app, 3d modeling/rendering apps, simluations, etc. I would
conceed, though, that larger allocation sizes are perhaps not common in a
majority of applications and application domains.

• Follow-Ups:
  • Re: Performance of the Darwin 6.6 Libc malloc()
    • From: Chris Ridd <email@hidden>

• Prev by Date: Re: Performance of the Darwin 6.6 Libc malloc()
• Next by Date: Re: 64 bit addressing
• Previous by thread: Re: Performance of the Darwin 6.6 Libc malloc()
• Next by thread: Re: Performance of the Darwin 6.6 Libc malloc()
• Index(es):
  • Date
  • Thread