Is it necessary to use autoreleasepool in a Swift program?












77















On page 17 of this WWDC14 presentation, it says




Working with Objective-C? Still have to manage autorelease pools

autoreleasepool { /* code */ }




What does that mean? Does it mean that if my code base doesn't have any Objective-C files, autoreleasepool {} is unnecessary?



In an answer of a related question, there is an example where autoreleasepool can be useful:



- (void)useALoadOfNumbers {
for (int j = 0; j < 10000; ++j) {
@autoreleasepool {
for (int i = 0; i < 10000; ++i) {
NSNumber *number = [NSNumber numberWithInt:(i+j)];
NSLog(@"number = %p", number);
}
}
}
}


If the code above gets translated into Swift with autoreleasepool dropped, will Swift be smart enough to know that the number variable should be released after the first } (like some other languages does)?










share|improve this question




















  • 1





    There appears to be no documentation on autoreleasepool in Swift. I expanded on your question and asked it in the dev forums.

    – Aaron Brager
    Sep 16 '14 at 7:32
















77















On page 17 of this WWDC14 presentation, it says




Working with Objective-C? Still have to manage autorelease pools

autoreleasepool { /* code */ }




What does that mean? Does it mean that if my code base doesn't have any Objective-C files, autoreleasepool {} is unnecessary?



In an answer of a related question, there is an example where autoreleasepool can be useful:



- (void)useALoadOfNumbers {
for (int j = 0; j < 10000; ++j) {
@autoreleasepool {
for (int i = 0; i < 10000; ++i) {
NSNumber *number = [NSNumber numberWithInt:(i+j)];
NSLog(@"number = %p", number);
}
}
}
}


If the code above gets translated into Swift with autoreleasepool dropped, will Swift be smart enough to know that the number variable should be released after the first } (like some other languages does)?










share|improve this question




















  • 1





    There appears to be no documentation on autoreleasepool in Swift. I expanded on your question and asked it in the dev forums.

    – Aaron Brager
    Sep 16 '14 at 7:32














77












77








77


24






On page 17 of this WWDC14 presentation, it says




Working with Objective-C? Still have to manage autorelease pools

autoreleasepool { /* code */ }




What does that mean? Does it mean that if my code base doesn't have any Objective-C files, autoreleasepool {} is unnecessary?



In an answer of a related question, there is an example where autoreleasepool can be useful:



- (void)useALoadOfNumbers {
for (int j = 0; j < 10000; ++j) {
@autoreleasepool {
for (int i = 0; i < 10000; ++i) {
NSNumber *number = [NSNumber numberWithInt:(i+j)];
NSLog(@"number = %p", number);
}
}
}
}


If the code above gets translated into Swift with autoreleasepool dropped, will Swift be smart enough to know that the number variable should be released after the first } (like some other languages does)?










share|improve this question
















On page 17 of this WWDC14 presentation, it says




Working with Objective-C? Still have to manage autorelease pools

autoreleasepool { /* code */ }




What does that mean? Does it mean that if my code base doesn't have any Objective-C files, autoreleasepool {} is unnecessary?



In an answer of a related question, there is an example where autoreleasepool can be useful:



- (void)useALoadOfNumbers {
for (int j = 0; j < 10000; ++j) {
@autoreleasepool {
for (int i = 0; i < 10000; ++i) {
NSNumber *number = [NSNumber numberWithInt:(i+j)];
NSLog(@"number = %p", number);
}
}
}
}


If the code above gets translated into Swift with autoreleasepool dropped, will Swift be smart enough to know that the number variable should be released after the first } (like some other languages does)?







memory-management swift






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 23 '17 at 11:47









Community

11




11










asked Sep 16 '14 at 4:55









EthanEthan

13.6k124262




13.6k124262








  • 1





    There appears to be no documentation on autoreleasepool in Swift. I expanded on your question and asked it in the dev forums.

    – Aaron Brager
    Sep 16 '14 at 7:32














  • 1





    There appears to be no documentation on autoreleasepool in Swift. I expanded on your question and asked it in the dev forums.

    – Aaron Brager
    Sep 16 '14 at 7:32








1




1





There appears to be no documentation on autoreleasepool in Swift. I expanded on your question and asked it in the dev forums.

– Aaron Brager
Sep 16 '14 at 7:32





There appears to be no documentation on autoreleasepool in Swift. I expanded on your question and asked it in the dev forums.

– Aaron Brager
Sep 16 '14 at 7:32












2 Answers
2






active

oldest

votes


















161














The autoreleasepool pattern is used in Swift when returning autorelease objects (created by either your Objective-C code or using Cocoa classes). The autorelease pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage/UIImage objects):



func useManyImages() {
let filename = pathForResourceInBundle

for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}


If you run this in Instruments, you'll see an allocations graph like the following:



with autoreleasepool



But if you do it without the autorelease pool, you'll see that peak memory usage is higher:



without autoreleasepool



The autoreleasepool allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.



Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool pattern is still useful.






share|improve this answer





















  • 2





    On all of these questions, you can write your own class, and have it do a println in deinit, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).

    – Rob
    Sep 17 '14 at 20:49






  • 3





    @StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).

    – Rob
    Oct 27 '14 at 14:46






  • 1





    @matt Yeah, I saw similar behavior. So I repeated my exercise with NSImage/UIImage objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.

    – Rob
    Feb 7 '15 at 20:23








  • 1





    I found an example that works! Just call NSBundle's pathForResource:ofType: repeatedly.

    – matt
    Feb 8 '15 at 2:00






  • 1





    My pathForResource:ofType: example no longer works in Xcode 6.3 / Swift 1.2. :)

    – matt
    Feb 13 '15 at 20:03



















4














If you would use it in the equivalent Objective-C code, then you would use it in Swift.




will Swift be smart enough to know that the number variable should be
released after the first }




Only if Objective-C does. Both operate along the Cocoa memory management rules.



Of course ARC knows that number goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:] may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:].






share|improve this answer



















  • 1





    If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?

    – Ethan
    Sep 16 '14 at 23:19






  • 8





    @Ethan It would appear that native Swift objects are not autorelease objects, and the autoreleasepool construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool construct becomes useful.

    – Rob
    Sep 17 '14 at 3:46











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25860942%2fis-it-necessary-to-use-autoreleasepool-in-a-swift-program%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









161














The autoreleasepool pattern is used in Swift when returning autorelease objects (created by either your Objective-C code or using Cocoa classes). The autorelease pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage/UIImage objects):



func useManyImages() {
let filename = pathForResourceInBundle

for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}


If you run this in Instruments, you'll see an allocations graph like the following:



with autoreleasepool



But if you do it without the autorelease pool, you'll see that peak memory usage is higher:



without autoreleasepool



The autoreleasepool allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.



Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool pattern is still useful.






share|improve this answer





















  • 2





    On all of these questions, you can write your own class, and have it do a println in deinit, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).

    – Rob
    Sep 17 '14 at 20:49






  • 3





    @StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).

    – Rob
    Oct 27 '14 at 14:46






  • 1





    @matt Yeah, I saw similar behavior. So I repeated my exercise with NSImage/UIImage objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.

    – Rob
    Feb 7 '15 at 20:23








  • 1





    I found an example that works! Just call NSBundle's pathForResource:ofType: repeatedly.

    – matt
    Feb 8 '15 at 2:00






  • 1





    My pathForResource:ofType: example no longer works in Xcode 6.3 / Swift 1.2. :)

    – matt
    Feb 13 '15 at 20:03
















161














The autoreleasepool pattern is used in Swift when returning autorelease objects (created by either your Objective-C code or using Cocoa classes). The autorelease pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage/UIImage objects):



func useManyImages() {
let filename = pathForResourceInBundle

for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}


If you run this in Instruments, you'll see an allocations graph like the following:



with autoreleasepool



But if you do it without the autorelease pool, you'll see that peak memory usage is higher:



without autoreleasepool



The autoreleasepool allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.



Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool pattern is still useful.






share|improve this answer





















  • 2





    On all of these questions, you can write your own class, and have it do a println in deinit, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).

    – Rob
    Sep 17 '14 at 20:49






  • 3





    @StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).

    – Rob
    Oct 27 '14 at 14:46






  • 1





    @matt Yeah, I saw similar behavior. So I repeated my exercise with NSImage/UIImage objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.

    – Rob
    Feb 7 '15 at 20:23








  • 1





    I found an example that works! Just call NSBundle's pathForResource:ofType: repeatedly.

    – matt
    Feb 8 '15 at 2:00






  • 1





    My pathForResource:ofType: example no longer works in Xcode 6.3 / Swift 1.2. :)

    – matt
    Feb 13 '15 at 20:03














161












161








161







The autoreleasepool pattern is used in Swift when returning autorelease objects (created by either your Objective-C code or using Cocoa classes). The autorelease pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage/UIImage objects):



func useManyImages() {
let filename = pathForResourceInBundle

for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}


If you run this in Instruments, you'll see an allocations graph like the following:



with autoreleasepool



But if you do it without the autorelease pool, you'll see that peak memory usage is higher:



without autoreleasepool



The autoreleasepool allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.



Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool pattern is still useful.






share|improve this answer















The autoreleasepool pattern is used in Swift when returning autorelease objects (created by either your Objective-C code or using Cocoa classes). The autorelease pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage/UIImage objects):



func useManyImages() {
let filename = pathForResourceInBundle

for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}


If you run this in Instruments, you'll see an allocations graph like the following:



with autoreleasepool



But if you do it without the autorelease pool, you'll see that peak memory usage is higher:



without autoreleasepool



The autoreleasepool allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.



Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool pattern is still useful.







share|improve this answer














share|improve this answer



share|improve this answer








edited Sep 19 '15 at 0:16

























answered Sep 16 '14 at 23:43









RobRob

304k50573739




304k50573739








  • 2





    On all of these questions, you can write your own class, and have it do a println in deinit, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).

    – Rob
    Sep 17 '14 at 20:49






  • 3





    @StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).

    – Rob
    Oct 27 '14 at 14:46






  • 1





    @matt Yeah, I saw similar behavior. So I repeated my exercise with NSImage/UIImage objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.

    – Rob
    Feb 7 '15 at 20:23








  • 1





    I found an example that works! Just call NSBundle's pathForResource:ofType: repeatedly.

    – matt
    Feb 8 '15 at 2:00






  • 1





    My pathForResource:ofType: example no longer works in Xcode 6.3 / Swift 1.2. :)

    – matt
    Feb 13 '15 at 20:03














  • 2





    On all of these questions, you can write your own class, and have it do a println in deinit, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).

    – Rob
    Sep 17 '14 at 20:49






  • 3





    @StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).

    – Rob
    Oct 27 '14 at 14:46






  • 1





    @matt Yeah, I saw similar behavior. So I repeated my exercise with NSImage/UIImage objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.

    – Rob
    Feb 7 '15 at 20:23








  • 1





    I found an example that works! Just call NSBundle's pathForResource:ofType: repeatedly.

    – matt
    Feb 8 '15 at 2:00






  • 1





    My pathForResource:ofType: example no longer works in Xcode 6.3 / Swift 1.2. :)

    – matt
    Feb 13 '15 at 20:03








2




2





On all of these questions, you can write your own class, and have it do a println in deinit, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).

– Rob
Sep 17 '14 at 20:49





On all of these questions, you can write your own class, and have it do a println in deinit, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).

– Rob
Sep 17 '14 at 20:49




3




3





@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).

– Rob
Oct 27 '14 at 14:46





@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).

– Rob
Oct 27 '14 at 14:46




1




1





@matt Yeah, I saw similar behavior. So I repeated my exercise with NSImage/UIImage objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.

– Rob
Feb 7 '15 at 20:23







@matt Yeah, I saw similar behavior. So I repeated my exercise with NSImage/UIImage objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.

– Rob
Feb 7 '15 at 20:23






1




1





I found an example that works! Just call NSBundle's pathForResource:ofType: repeatedly.

– matt
Feb 8 '15 at 2:00





I found an example that works! Just call NSBundle's pathForResource:ofType: repeatedly.

– matt
Feb 8 '15 at 2:00




1




1





My pathForResource:ofType: example no longer works in Xcode 6.3 / Swift 1.2. :)

– matt
Feb 13 '15 at 20:03





My pathForResource:ofType: example no longer works in Xcode 6.3 / Swift 1.2. :)

– matt
Feb 13 '15 at 20:03













4














If you would use it in the equivalent Objective-C code, then you would use it in Swift.




will Swift be smart enough to know that the number variable should be
released after the first }




Only if Objective-C does. Both operate along the Cocoa memory management rules.



Of course ARC knows that number goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:] may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:].






share|improve this answer



















  • 1





    If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?

    – Ethan
    Sep 16 '14 at 23:19






  • 8





    @Ethan It would appear that native Swift objects are not autorelease objects, and the autoreleasepool construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool construct becomes useful.

    – Rob
    Sep 17 '14 at 3:46
















4














If you would use it in the equivalent Objective-C code, then you would use it in Swift.




will Swift be smart enough to know that the number variable should be
released after the first }




Only if Objective-C does. Both operate along the Cocoa memory management rules.



Of course ARC knows that number goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:] may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:].






share|improve this answer



















  • 1





    If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?

    – Ethan
    Sep 16 '14 at 23:19






  • 8





    @Ethan It would appear that native Swift objects are not autorelease objects, and the autoreleasepool construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool construct becomes useful.

    – Rob
    Sep 17 '14 at 3:46














4












4








4







If you would use it in the equivalent Objective-C code, then you would use it in Swift.




will Swift be smart enough to know that the number variable should be
released after the first }




Only if Objective-C does. Both operate along the Cocoa memory management rules.



Of course ARC knows that number goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:] may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:].






share|improve this answer













If you would use it in the equivalent Objective-C code, then you would use it in Swift.




will Swift be smart enough to know that the number variable should be
released after the first }




Only if Objective-C does. Both operate along the Cocoa memory management rules.



Of course ARC knows that number goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:] may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:].







share|improve this answer












share|improve this answer



share|improve this answer










answered Sep 16 '14 at 20:19









newacctnewacct

95.7k23134196




95.7k23134196








  • 1





    If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?

    – Ethan
    Sep 16 '14 at 23:19






  • 8





    @Ethan It would appear that native Swift objects are not autorelease objects, and the autoreleasepool construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool construct becomes useful.

    – Rob
    Sep 17 '14 at 3:46














  • 1





    If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?

    – Ethan
    Sep 16 '14 at 23:19






  • 8





    @Ethan It would appear that native Swift objects are not autorelease objects, and the autoreleasepool construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool construct becomes useful.

    – Rob
    Sep 17 '14 at 3:46








1




1





If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?

– Ethan
Sep 16 '14 at 23:19





If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?

– Ethan
Sep 16 '14 at 23:19




8




8





@Ethan It would appear that native Swift objects are not autorelease objects, and the autoreleasepool construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool construct becomes useful.

– Rob
Sep 17 '14 at 3:46





@Ethan It would appear that native Swift objects are not autorelease objects, and the autoreleasepool construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool construct becomes useful.

– Rob
Sep 17 '14 at 3:46


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25860942%2fis-it-necessary-to-use-autoreleasepool-in-a-swift-program%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







這個網誌中的熱門文章

Xamarin.form Move up view when keyboard appear

Post-Redirect-Get with Spring WebFlux and Thymeleaf

Anylogic : not able to use stopDelay()