Re: NSAutoreleasePool: how does it really work?
Re: NSAutoreleasePool: how does it really work?
- Subject: Re: NSAutoreleasePool: how does it really work?
- From: Oleg Svirgstin <email@hidden>
- Date: Tue, 18 Mar 2003 20:36:13 +0300
IMHO, NSAutoreleasePool works fantastic, the only thing it is unfortunately
missing is capability to show, say, class of the offending object.
Say, in some super-debug mode. Say, representing zero refcount as 1 000 000,
and raising with details on every instance asked to release being 1 000 000
or less. Or deallocate instances when their recount reaches, say, - 1 000
000.
PoolBombSquad mode. Finding all possible information about the crasher.
Such pool accidents killed a lot of my time and nerves few months ago, and
now, though rarely, such things do happen... Multiplied by thousands of
newbies this time grows into lost, sad and nervous millennia...
Wow, is there a solution within our reach? It would be a nice little tool...
And now let me enjoy some RANT... I love flames, rants and everything that
takes me away from programming for few happy minutes.
Indeed, there must be some secret life behind every applications' back...
Why should we know everything about their PRIVATE life? Do not oppress them
too much, and they will generally just work.
How often in the real life do we need loops of 500 000 iterations where
every step allocates and deallocates ObjC instances?
Even if there is a need for such an infinite loop, it is an obvious subject
to severe optimization of its body by all means... It is a point where NO
memory allocations in traditional way should happen. Probably nothing but
plain C is good there. As much as possible of operations must be put outside
the loop's body.
Here we just allocate, allocate, resize and deallocate. If I were mach
kernel, I would run to the wood...
Well, we don't even know how we ourselves work... :)
Regards
Oleg
>
From: Sujal Shah <email@hidden>
>
Date: 18 Mar 2003 10:52:10 -0500
>
To: email@hidden
>
Subject: Re: NSAutoreleasePool: how does it really work?
>
>
Have you verified that your output from top or ps is accurate? In other
>
words, written a simple application where you don't autorelease? So,
>
just write a simple application and verify that your monitoring
>
methodology is accurate. I seem to remember that those numbers are
>
flaky at best in terms of accuracy... but, maybe that's just a linux
>
thing (where most of my experience is...).
>
>
Sujal
>
>
>
On Tue, 2003-03-18 at 10:35, Lorenzo Puleo wrote:
>
> Hi Phill,
>
> Thank you for your detailed reply. You gave me fine informations.
>
>
>
> I think Rsize means Real Size an application is using. More than this I can
>
> see the Free Memory decreases while the Rsize increases. Look here belowe
>
> the free memory is 328M before running the routine and 302M at the end.
>
>
>
> Before running the routine
>
> ===========================
>
> Processes: 43 total, 2 running, 41 sleeping... 103 threads
>
> 16:11:18
>
> Load Avg: 0.56, 0.40, 0.34 CPU usage: 52.6% user, 17.5% sys, 29.8% idl
>
> SharedLibs: num = 90, resident = 20.5M code, 2.61M data, 7.36M LinkEdit
>
> MemRegions: num = 2392, resident = 16.8M + 8.26M private, 35.2M shared
>
> PhysMem: 46.9M wired, 56.5M active, 81.1M inactive, 184M used, 328M free
>
> VM: 2.00G + 51.8M 5047(1) pageins, 0(0) pageouts
>
>
>
> PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
>
> 409 MyApp 0.0% 0:00.99 1 60 130 3.00M 7.04M 8.57M 105M
>
>
>
>
>
> After running the routine
>
> ===========================
>
> Processes: 43 total, 2 running, 41 sleeping... 104 threads
>
> 16:11:50
>
> Load Avg: 0.25, 0.35, 0.31 CPU usage: 2.9% user, 3.8% sys, 93.3% idle
>
> SharedLibs: num = 90, resident = 20.7M code, 2.61M data, 7.36M LinkEdit
>
> MemRegions: num = 2512, resident = 41.7M + 8.26M private, 35.5M shared
>
> PhysMem: 47.1M wired, 56.9M active, 106M inactive, 210M used, 302M free
>
> VM: 2.03G + 51.8M 5109(0) pageins, 0(0) pageouts
>
>
>
> PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
>
> 409 MyApp 0.0% 0:05.77 1 60 229 27.7M 7.14M 33.2M 130M
>
>
>
>
>
> This time I used the following code:
>
> ===========================
>
> - (IBAction)MyLoop:(id)sender
>
> {
>
> int i;
>
> xArray = [NSMutableArray array];
>
>
>
> for ( i = 0; i < 500000; i++ )
>
> {
>
> NSAutoreleasePool *myPool = [[NSAutoreleasePool alloc] init];
>
> [xArray addObject:[NSString stringWithFormat: @"Don't leak, step
>
> %d", i]];
>
> [myPool release];
>
> }
>
> [xArray removeAllObjects];
>
> return;
>
>
>
> }
>
>
>
>
>
> Sincerely I am afraid that I am doing something wrong.
>
> If I run the loop for a bigger number of steps (100,000,000)
>
> I see the free memory goes near zero, then the numbers of pageouts
>
> increases. And at the end of the routine, my application keeps the CPU busy
>
> for so long time because it has to clean the files used by the virtual
>
> memory. And however the Rsize and the Free Mem don't come back to the
>
> initial values.
>
>
>
>
>
> Best Regards
>
--
>
---- Sujal Shah --- email@hidden ---
>
>
http://www.sujal.net
>
>
Now Playing: George Michael - Listen Without Prejudice - 001 - Praying for
>
time
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.