• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unexpected behaviour with autorelease pool
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unexpected behaviour with autorelease pool


  • Subject: Re: Unexpected behaviour with autorelease pool
  • From: Filip van der Meeren <email@hidden>
  • Date: Sun, 14 Dec 2008 23:17:54 +0100

I suggest you run my code, on your system.
Do not start up leaks, start up Activity Monitor and watch your memory closely.
If your system doesn't crash/hangs before you can stop it, then you will see that the app is consuming memory like the Americans are consuming oil.
And according to me, my program respects the Memory Management rules. So I say there is a bug.


Filip van der Meeren
email@hidden
http://www.sourceforge.net/projects/perlmanager
http://www.sourceforge.net/projects/xlinterpreter

On 14 Dec 2008, at 23:14, Ken Thomases wrote:

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


  • Follow-Ups:
    • Re: Unexpected behaviour with autorelease pool
      • From: Ken Thomases <email@hidden>
References: 
 >Unexpected behaviour with autorelease pool (From: "Krishna Kotecha" <email@hidden>)
 >Re: Unexpected behaviour with autorelease pool (From: Filip van der Meeren <email@hidden>)
 >Re: Unexpected behaviour with autorelease pool (From: Ken Thomases <email@hidden>)
 >Re: Unexpected behaviour with autorelease pool (From: Filip van der Meeren <email@hidden>)
 >Re: Unexpected behaviour with autorelease pool (From: Ken Thomases <email@hidden>)

  • Prev by Date: Re: first responder stopped working
  • Next by Date: Re: Unexpected behaviour with autorelease pool
  • Previous by thread: Re: Unexpected behaviour with autorelease pool
  • Next by thread: Re: Unexpected behaviour with autorelease pool
  • Index(es):
    • Date
    • Thread