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:57:34 -0600
On Dec 14, 2008, at 4:38 PM, Filip van der Meeren wrote:
[...] NSNumber is the basic foundation of our OS, I know dozens of
ways to create the object without autoreleasing it inside somewhere.
Really? Since you're invoking closed-source framework code, it's hard
to imagine how you can possibly know that. And even if you had the
source code to look at, or you looked at its disassembly, that doesn't
change the fact that it is only responsible for its contractual
obligations. And within those obligations, it's free to create and
autorelease intermediate temporary objects, or return to you an object
which has been retained and autoreleased (on top of the one reference
ownership that you definitely receive).
There has to be a better way to do this, this isn't just some other
virtual machine that releases objects when its pool is full. This is
native, no garbage collector is going to save us!
That is why I think that the basic building blocks of our framework
should be able to create themselves without putting a big restraint
on the system.
What big constraint? I think you mean a tiny constraint magnified
many times over by your own deliberate iteration. When you do that,
you are responsible for draining the autorelease pool on a regular
basis.
But even with lots of iteration, I don't see the big constraint. I
actually did run your code. It completed in under 40 milliseconds
with no evident strain on my system. It completed so quickly that I
didn't even have the opportunity to see its memory usage in Activity
Monitor.
Thinking that you perhaps meant a loop of 100,000 invocations of your
code, with its own 100,000-iteration loop inside, I tried that. It
takes longer, and uses nearly 100% of one of my CPU cores, of course,
but its memory usage is constant and my system is still perfectly
responsive. (I changed the NSLog call to printf to avoid polluting my
console log with 100,000 copies of the output line.)
For reference, I'm using a 2.4 GHz iMac with 2GB of RAM. Mac OS X
10.5.5.
They just prevent leaks. But not all memory consumption
constitutes a leak.
But they are a pain in the buttocks, and certainly if you want to
create a small but efficient terminal app.
Huh? What's the "they" in the above statement? What's preventing you
from creating small, efficient terminal tools?
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