> On Apr 25, 2017, at 4:11 PM, Charles Srstka <[email protected]> wrote: > > Have to disagree with this statement. I have, more than once, spent some time > tracking down severe performance issues in Pacifist, only to have it turn out > that the problem was caused by an atomic property being accessed in a loop.
+1. Different projects have different types of code, and I think a lot of the “don’t worry about micro-optimizations, _____ doesn’t really affect your performance” statements apply to high-level code like in a typical app, but do not apply to lower-level code that’s doing heavy lifting. In my case, I work on a document-oriented database engine that has some very performance-critical code in it, and overhead like atomic properties is very noticeable in Instruments in some areas. From Jonathan’s blog post: > The mutex you are so scared of is actually not a mutex: It's a spinlock (see > the code linked above) with very low contention. It’s not clear how much overhead there is in locating that spinlock, though. It’s accessed as "PropertyLocks[slot]”, where PropertyLocks is a global C++ object of class StripedMap. I haven’t looked up the implementation of StripedMap, but this is a global table with an entry for every atomic property of every object in memory. And that table needs to be thread-safe, so it either has its own locks, or it has a complex lockless algorithm that relies on atomic instructions (which are themselves expensive as they invalidate CPU caches.) > The cost of atomic is roughly that of a single retain. Nope, it’s a retain plus an autorelease, plus the work of doing the deferred release while draining the autorelease table. (Retain and release also involve accessing global tables indexed by object. IIRC these are lockless; Mike Ash has delved into the implementation on his blog.) objc_retain and objc_release are other very hot functions in typical Instruments profiles I look at. To the point that I’ve started using _unsafe_unretained in method/function implementation signatures to prevent parameters from getting retained/released unnecessarily (I’ve got a macro “UU” for it.) Yes, I see real-world gains for this when I use it in very hot functions. Your point [Jonathan] about releasing dangling references is valid, Jonathan; but in practice I run into this problem very rarely, and I’ve been using nonatomic properties (and getters that simply “return _obj” without the retain/autorelease dance) since 2000. For me the tradeoff is worth it. For people writing typical app code, maybe not. But I think the description in your blog post is a bit one-sided. —Jens
_______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
