Re: Unexpected behaviour with autorelease pool
Re: Unexpected behaviour with autorelease pool
- Subject: Re: Unexpected behaviour with autorelease pool
- From: Ken Thomases <email@hidden>
- Date: Sun, 14 Dec 2008 16:14:43 -0600
On Dec 14, 2008, at 4:01 PM, Filip van der Meeren wrote:
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSNumber *n = nil;
NSInteger whaaaa = 0;
srand(time(NULL));
for(int i = 0; i < 100 * 1000; ++i)
{
n = [[NSNumber alloc] initWithInt:rand()];
if([n retainCount])
++whaaaa;
[n release];
}
NSLog(@"Result: %d", whaaaa);
[pool release];
then you should be able to release it. OS X can't cache random
numbers...
I dumped the code above in a forloop, running 100,000 times... with
random numbers to be inserted.
Memory-requirements started to go up, up and up...
And guess what the value of "whaaaa" was ? That is right: 100,000!
And you imagine this proves what, exactly?
Of course whaaaa is 100,000. What else could it be? Your "if([n
retainCount])" will (and should) always evaluate to true.
With respect to a constantly increasing memory requirement, that
doesn't contradict anything you're entitled to expect from memory
management. Nobody made any promises to you that the allocation and
initialization of an NSNumber instance did not allocate and then
autorelease some intermediate objects. It has always been possible
that loops like yours might accumulate autoreleased objects, even if
you yourself are not autoreleasing objects (or using convenience
constructors which often, but not always, return autoreleased objects).
Again, what were you trying to prove?
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden