4 ms·
This answer says the block is more efficient than manually managing NSAutoreleasePool objects: https://stackoverflow.com/a/12448176 https://stackoverflow.com/a/
by lunixbochs 6y ago
This answer says the block is more efficient than manually managing NSAutoreleasePool objects: https://stackoverflow.com/a/12448176 https://stackoverflow.com/a/12448176
This answer looks like a better overview of what the runtime is doing: https://stackoverflow.com/a/21010442 https://stackoverflow.com/a/21010442
The @autoreleasepool block seems equivalent to this:
ctx = _objc_autoreleasePoolPush()
defer _objc_autoreleasePoolPop(ctx)
You could maybe provide sugar for it like this: https://play.golang.org/p/dljXN3BdEGr https://play.golang.org/p/dljXN3BdEGr
- progrium 6y agoAwesome, can you throw into an issue?
- lunixbochs 6y agoDone https://github.com/progrium/macdriver/issues/12 https://github.com/progrium/macdriver/issues/12
- progrium 6y agowow, thanks!
- favorited 6y agoKeep in mind that the reason the `@autorelease` syntax is faster is primarily due to ARC optimizations (which don't apply here, since you're not using ARC). Calling the `_objc_autoreleasePoolXX` functions are still likely to be faster than the NSAutoreleasePool objects, but only because you're avoiding the Objective-C message sends.
- dolmen 6y agoThe implementation of your "sugar" can be shortened: https://play.golang.org/p/8v4EL2B_c_t https://play.golang.org/p/8v4EL2B_c_t