David Smith
This makes me feel old, but lately I've been seeing misunderstandings about what autorelease actually is in objc/swift. "It's a GC", "it's weird magic", "it's a batch allocator", etc…
Autorelease is just an array. You (or, 99% of the time, SDK methods you're calling) manually put things into the array by calling `autorelease` on them, and then when you reach the closing brace of the autoreleasepool {} block, it calls `release` on anything that was added.
That's literally all it is.
David Smith
Autorelease tidbits:
RunLoops wrap your code in autoreleasepool {} before calling it; so does Swift Concurrency
DispatchQueues don't, by default! Configure them with .workItem autorelease frequency to fix this
It's much less overhead than you'd expect from my description
swiftc can autorelease objects when returning them from @objc methods
Neither ObjC nor Swift ARC will autorelease things other than that
Use "Allocations" in Instruments to see where adding a pool would help
Paul Cantrell
@Catfish_Man
Something I realized I don’t know: does the Swift compiler’s ARC ever inject an object autorelease? Or it is always explitict / from libraries?
David Smith
@inthehands it's *surprisingly* hard to get it to stop doing it for return values from @\objc methods!
I've even resorted to lying about the return type and returning an Unmanaged<Foo> instead, since ObjC doesn't care as long as the representation is just a pointer.
Not aware of any situations where it will other than that one though.
Paul Cantrell
@Catfish_Man
Thanks!
And, re autoreleasing every return value: I seem to remember that I did that back in the pre-ARC days, so…I can hardly blame it!
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.