• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Speed Traps
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Speed Traps


  • Subject: Re: Speed Traps
  • From: Kevin Elliott <email@hidden>
  • Date: Sun, 18 May 2003 17:20:44 -0700

At 21:51 +0200 on 5/16/03, Marcel Weiher wrote:
The way autoreleases pools are implemented is (essentially) as a list of objects (it would be very easy to implement them using NSMutableArray, but I don't know if they are done that way).

I am not so sure that retaining the objects in the autorelease pool (which is >what NSMutableArray would do) is such a good idea...

Why? You call release on every object in the array, then you remove all objects from the array and your done. I suspect (hope) apple's implementation is more efficient, but I think my description is pretty accurate as to the straightforward implementation.

Apples docs on the performance of Autorelease pools is somewhat misleading (in my opinion). If you don't allocate anymore objects than you "normally" would the performance is nearly the same as for manually calling release.

This turns out not to be the case. I have done extensive benchmarking of >various aspects of Cocoa memory management, including allocation, deallocation, >reference counting and pools. Autorelease pools are significantly slower than a plain retain. Of course, NSObject's extra-reference count implementation is so incredibly slow that the difference isn't all that noticeable, but if you've implemented an inline refcount or are using one of the built-in classes, then the difference is very signiifcant.

With all due respect, how is "the performance is nearly the same" very different than "the difference isn't all that noticeable"? Yes, there is a performance difference and if you, for whatever reason, do your own memory management it may become noticeable. But in the standard situation the performance is the same.

For example, the "autoreleasing accessor" that is sometimes recommended by Apple happens to be roughly 10 times slower than the "canonical accessor" that just about everyone else recommends.

Yes it's slower. I'm not sure I buy 10 times slower, and I'd like to see how it was benchmarked. Apple's argument is based purely on stability, not speed, in which case it probably wins.

But again the point of all this is that his autoreleasing version is NOT faster than his manual release code. He's simply not including the deallocate time in his autorelease version.
--
__________________________________________
Kevin Elliott <mailto:email@hidden>
ICQ#23758827 AIM ID: teargo
__________________________________________
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
  • Follow-Ups:
    • Re: Speed Traps
      • From: Marcel Weiher <email@hidden>
References: 
 >Re: Speed Traps (From: Marcel Weiher <email@hidden>)

  • Prev by Date: Re: Memory and stringByAppendingString
  • Next by Date: Re: OT: WWDC
  • Previous by thread: Re: Speed Traps
  • Next by thread: Re: Speed Traps
  • Index(es):
    • Date
    • Thread