On 14 Dec 2008, at 23:57, Ken Thomases wrote:
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).
I am basing my comments on
http://www.koders.com/objectivec/fid92844506886795F3D6CA4417B418B12A1F7EB99B.aspx?s=NSGetSizeAndAlignment
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
I do know that it is impossible for me to win the autorelease war, I
personally love NSAutoreleasePool, and at the same time hate it.
So I am going to stop this discussion.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
