Re: NSEnumerator retaining objects?
Re: NSEnumerator retaining objects?
- Subject: Re: NSEnumerator retaining objects?
- From: James Bucanek <email@hidden>
- Date: Wed, 9 Mar 2005 13:04:27 -0700
John Stiles wrote on Wednesday, March 9, 2005:
>So it's not zero overhead, sure, but I honestly wouldn't expect any of this to
>affect real-world performance measurements.
Normally, I would agree with you. But in my instance, I'm iterating through a tree of (potentially) 10,000,000 objects.
>Certainly not enough overhead to generate this much list traffic.
As they say in academia: The battles are so fierce, because the stakes are so small. ;)
>So is there another performance implication I'm missing?
Memory: (For me) The problem with NSEnumumerator retaining and autoreleasing each object is that the mere act of iterating through a bunch of collections leaves every one of those objects retained by the autorelease pool.
I have (potentially) about 10 million of these things. Having 10,000,000 objects stuck in an autorelease pool removes the ability to immediately release them (meaning about 600+ MB of memory) and I'm stuck with an autorelease pool that's at least 40MB in size (10,000,000*sizeof(id)).
It was the memory footprint that was killing my app, and I couldn't figure out why. I discovered this in ObjectAlloc, not Shark. The CPU overhead of the retain/autorelease didn't even make a blip on Shark's radar. But the VM swapping brought my app to it's knees.
--
James Bucanek <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden