[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSZone pointers
From: |
David Chisnall |
Subject: |
Re: NSZone pointers |
Date: |
Thu, 21 Jul 2011 14:27:16 +0100 |
On 21 Jul 2011, at 14:16, Ivan Vučica wrote:
> I didn't even bother looking up what zones are for until now.
They're not used very much anymore, because half of Cocoa is not zone-aware.
On OS X, zones are opaque, so they're not even very useful, they just act as
hints for the allocation policy.
> Judging by information on CocoaDev, it looks to me like zones might primarily
> be interesting to games, screensavers and other continuously-rendered and
> high-performance applications.
Not really. They were mainly used on OPENSTEP for optimisation where lots of
short-lived objects that would never be aliased were created and destroyed at
once. Generally though, if that's the problem then the right solution is to
use C structure rather than objects. Given the throughput of a modern malloc()
implementation, it's largely irrelevant.
I've done some things with zones in the past, for example defining a persistent
zone backed by an mmap()'d segment, so that objects could persist between
program invocations (needed some hacks to update their isa pointers on each
restart though, so it wasn't very useful), but I've not seen any post-NeXT code
that used them for anything.
> It would be interesting to have this as a ./configure-able setting when
> building the runtime, with the default being current behavior. Reducing RAM
> usage is not very important these days.
I disagree. Reducing RAM is still important, and in this case it's a trade:
either reduce RAM or reduce CPU cycles. I think we're optimising for the very
unlikely case and burning RAM.
More importantly, we're burning cache. Objects are allocated starting at the
zone pointer, which means that we're wasting one word of a cache line in every
object for a value that almost never needs to be accessed - every time you
touch an object, you'll be pulling it into cache. Reducing cache churn is
likely to make more of a performance difference than anything else in this diff
- on a modern system, efficient cache usage is one of the biggest factors in
performance.
David