On Fri, Jul 11, 2008 at 3:21 AM, Marcel Weiher <[EMAIL PROTECTED]> wrote:
>> [not referring to scanning overhead]
>>
>> - Temporary objects get a 'release' at the end of their life, and
>> usually an 'autorelease' at the beginning.
>
> The cost of a single refcounting op is negligible compared to the cost of
> object allocation, so these two are quite irrelevant.
A quick test of this claim would appear to disprove it. On my Mac Pro,
an alloc/init/release cycle of NSObject costs about 290ns. Adding an
extra pair of retain/release costs about 480ns. I'm not sure how I can
reasonably measure the object allocation by itself, or the cost of
just retain or just release. But it seems clear that these refcounting
operations are quite significant in cost.
>>> Yes, just like objects don't get retained when they are stored in local
>>> variables, that happens when you store them into instance variables.
>>
>> They do get released though, which is a refcount operation that
>> doesn't happen in the GC world.
>
> Once again, the -release is completely negligible compared to the actual
> deallocation.
Apparently not!
>>> Taking into account the programming style a language supports is about as
>>> far from a micro-optimization as you can get. It is an architectural
>>> concern that informs how you structure your system, changing it
>>> after-the-fact often turns out to be impossible. At least that's been my
>>> experience over the last 20 years or so, YMMV.
>>
>> I'm not sure I understand what you're saying here. My point is that
>> ObjC makes it very easy and natural to create temporary objects
>> without worrying about their lifetimes.
>
> That is exactly my point: this is one case where the comparative ease is
> deceptive, as creating lots of temporary objects is not something that
> Objective-C supports well. Objective-C is a *hybrid* OO language, not a
> pure OO language.
This disagrees completely with my experience. ObjC supports creating
lots of temporary objects very well. It may not be as *fast* at it as
some languages, but as you say, speed is not a concern in 90% of the
cases. Typical ObjC code creates a great deal of temporary objects,
and this usually works just fine.
>> In my experience, code which goes to great lengths to avoid autoreleased
>> objects is messy and much
>> more bug prone than the "normal" way.
>
> Yes, if it is autoreleasing you avoid, not object creation in the first
> place. The extra autorelease only costs you maybe 30%, the extra object
> allocation costs you an order of magnitude or more. So for example, my
> standard pattern for initialization is something like this:
>
> -init {
> self=[super init];
> [self setFoo:[Bar bar]];
> return self;
> }
I don't understand what you're trying to show with this example,
unless it's the fact that you don't avoid autorelease. But then this
directly contradicts what you said before: "Also: don't gratuitously
create and/or autorelease objects if you don't have to." So I'm
confused.
>> Thus, yes, you can avoid many
>> autoreleased objects if you want, but this is a painful micro
>> optimization, not the standard way to do things.
>
> Once again, avoiding temporary object-creation is not a micro-optimization,
It certainly is. You're improving the constant in your running time,
not improving the asymptotic algorithmic performance. That's a micro
optimization in my book.
> and creating lots of temporary objects is definitely NOT the standard way to
> do things in Objective-C.
It certainly has been in all of the ObjC code I've ever created or
worked with, and most of what I've looked at.
>>> You might have heard about the 80/20 rule, which is actually more a 90/10
>>> or
>>> 95/05 rule: most of the execution time is spent in a very small portion
>>> of
>>> your code. Being able to go in and *really* optimize those hotspots
>>> actually gives you the most bang for the buck. The "typical usage",
>>> meaning
>>> the bulk of the program, generally does not matter.
>>
>> I did my master's thesis on high performance code and optimization; I
>> am more than vaguely familiar with these concepts.
>
> Glad to hear that! However, in the sections above you were continually
> treating ops that differ in cost by an order of magnitude or more with equal
> weight, which makes me somewhat dubious of your claimed credentials...
Where did I ever treat anything with equal weight? I don't recall ever
stating or even implying that two different operations were
necessarily equally significant.
>> My point is merely that GC can help you without you needing to change your
>> code in any
>> way. This, to me, is more valuable than peppering my code with lots of
>> painful manual memory management to make it go faster.
>
> ...as does this. Once again: this is not about randomly "peppering" code
> with "lots of painful manual memory management", this is about (a) adopting
> a coding style that is clean, (b) flows with what Objective-C provides and
> is good at and (c) allows for the highly focused optimizations that actually
> make an impact, rather than wasting it on the parts of the code that don't
> matter.
Well, you're advocating avoiding object creation and avoiding
autoreleasing objects, which in my experience creates messy,
overly-long, bug-prone code. Points a, b, and c are all fulfilled by
using convenience constructors whenever possible and, in most cases,
not worrying about how many objects you're making.
>>> This is one of those areas where Objective-C really, really excels: the
>>> ability to combine very high-level, very abstracted code with small bits
>>> of
>>> highly optimized code to get an optimum balance of expressiveness and
>>> performance.
>>
>> I agree, but I don't agree with your proposed methods.
>
> I haven't seen any indication that you know what my proposed methods are.
> They certainly do not involve peppering code with micro-optimizations or
Seems to me that you've stated them pretty explicitly. Avoid
autorelease, avoid creating objects when you can, reuse objects with
caches when you can't avoid creating them. No?
>> I've optimized lots of ObjC code in my time, and I've never found it
>> necessary or
>> even particularly helpful to perform these refcounting or allocation
>> tricks you discuss. In my experience, object allocation and
>> refcounting are never hotspots.
>
> I've given some references to back up my claim...the Postscript interpreter
> I wrote in Objective-C is 20x faster because of object-caching, turning it
> from laughably slow to competitive with the industry standard. MPWXmlKit is
> around 10x faster than other XML scanners, again due in large part to object
> caching.
Yep, well, like I said, your experience differs.
>> Your experience may differ. In fact, I know that it *does* differ,
>> because we've had that conversation before. But, to be perfectly
>> frank, your experience is not going to change my mind.
>
> "I have my opinion, who cares about facts or evidence"
That is a gross misrepresentation of what I said. *Your* experience is
not going to override *my* experience.
Now you're just being abusive. Please stop it.
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
