Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance of the Darwin 6.6 Libc malloc()

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

Example: on the Test-Darwin-Linux-IRIX-65536-1048576-Real graph, at 300K
byte-sized allocations, we can perform roughly 20000 malloc's per second
on the Linux G4 (blue) curve. We should expect 40000 malloc's per second
at double the allocation size (600K), and we do.

As for the allocation sizes, it very much depends on your application
domain to say that those sizes are 'large'. The allocations shown on the
Test-Darwin-Linux-IRIX-65536-1048576-Real graph is for sizes between 65K
and 1MB in size. It's not uncommen for many applications to repeately
need to allocate such sizes, if not larger (hence the last chart shows
allocations from 1MB to 64MB). 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.

The Mac OS X curve that was performing rather poorly for smaller
allocation sizes appears to play a game of catch-up, where it indeed
catches up in a non-linear fashion. It then proceeds to outperform the
other implementations. That was the single impressive feature observed on
the Darwin allocation curve.

The curve mentioned is described in section 2.5 as well as section 6.5 in
http://intelligentcode.com/memoryTest/

The distressing feature about that same graph is the secondary curve at
the very bottom where the malloc implementation bottoms out. There are
certain allocation sizes where the Darwin malloc considerably
underperforms. Requesting allocations of those particular sizes could be
significantly impacting on an application's malloc performance.

Cheers!
Sean
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.