5 ms·

I guess I will look into this as that really sounds like syntactic sugar for something more basic. Like using the class. I have a hard time keeping up with the

I guess I will look into this as that really sounds like syntactic sugar for something more basic. Like using the class. I have a hard time keeping up with their changes but you might be right: https://developer.apple.com/documentation/foundation/nsautoreleasepool https://developer.apple.com/documentation/foundation/nsautor... Oddly it says you cannot use them directly, but later implies maybe they are just less efficient. It would be nice if somebody made an issue for this.

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 ago
  Awesome, can you throw into an issue?
  - lunixbochs 6y ago
    Done https://github.com/progrium/macdriver/issues/12 https://github.com/progrium/macdriver/issues/12
    - progrium 6y ago
      wow, thanks!
      - favorited 6y ago
        Keep 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 ago
  The implementation of your "sugar" can be shortened: https://play.golang.org/p/8v4EL2B_c_t https://play.golang.org/p/8v4EL2B_c_t
pjscott 6y ago
The page you linked is not actually ambiguous, though perhaps a bit tricky to read. It says: 1. If you're compiling Objective C in ARC mode, you can't use NSAutoreleasePool directly, and must instead use @autoreleasepool. 2. In manual reference counting mode you can use either NSAutoreleasePool or @autoreleasepool, but the latter has lower overhead. (This may matter if e.g. you're draining the autorelease pool on every iteration of a loop to reduce memory spikes.) Under the hood -- at least on the version I disassembled -- NSAutoreleasePool's -init and -release methods wrap the CoreFoundation CFAutoreleasePoolPush and CFAutoreleasePoolPop functions, which in turn call the runtime's objc_autoreleasePoolPush and objc_autoreleasePoolPop functions, which are the things that @autoreleasepool will cause the compiler to emit directly.

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 ago
Awesome, can you throw into an issue?
- lunixbochs 6y ago
  Done https://github.com/progrium/macdriver/issues/12 https://github.com/progrium/macdriver/issues/12
  - progrium 6y ago
    wow, thanks!
    - favorited 6y ago
      Keep 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 ago
The implementation of your "sugar" can be shortened: https://play.golang.org/p/8v4EL2B_c_t https://play.golang.org/p/8v4EL2B_c_t

pjscott 6y ago

The page you linked is not actually ambiguous, though perhaps a bit tricky to read. It says: 1. If you're compiling Objective C in ARC mode, you can't use NSAutoreleasePool directly, and must instead use @autoreleasepool. 2. In manual reference counting mode you can use either NSAutoreleasePool or @autoreleasepool, but the latter has lower overhead. (This may matter if e.g. you're draining the autorelease pool on every iteration of a loop to reduce memory spikes.) Under the hood -- at least on the version I disassembled -- NSAutoreleasePool's -init and -release methods wrap the CoreFoundation CFAutoreleasePoolPush and CFAutoreleasePoolPop functions, which in turn call the runtime's objc_autoreleasePoolPush and objc_autoreleasePoolPop functions, which are the things that @autoreleasepool will cause the compiler to emit directly.