Re: Working set bloat in Xcode 2
Re: Working set bloat in Xcode 2
- Subject: Re: Working set bloat in Xcode 2
- From: j o a r <email@hidden>
- Date: Wed, 25 May 2005 08:02:14 +0200
On 25 maj 2005, at 04.42, Nicko van Someren wrote:
Despite having 1GB in my laptop it is spending a great deal more
time thrashing the disk since moving to 10.4 and I'm wondering if
other people on this list have been experiencing the same with
their programs.
Are you sure that the disk activity you see are from VM paging? Is it
not possible that it's something else, like for example Spotlight
indexing? Check paging statistics in top, and use Shark to find out
more! As always with performance problems - don't guess, measure!
When you guess you're almost always wrong!
When it comes to your applications in particular, and not the
behaviour of Tiger in general, I'd suggest that you use top +
ObjectAlloc to check your apps on both Panther and Tiger and compare
the results. Try to use the same binary (use the Cross Dev SDK) and
have a predefined set of actions to be performed, to ensure that you
compare apples to apples.
On 25 maj 2005, at 05.47, email@hidden wrote:
To bring this back on topic, however, I'd like the pose the query -
has anyone tested their programs to see exactly when autorelease
pools are actually released?
I can't remember that we've had any problems with that, I would say
that they're released when expected - ie. at the end of every event
loop in the case of the default top level autorelease pool that you
get automatically in the main thread.
I sometimes wonder about Cocoa apps which use a lot of memory for a
task, and then don't seem to release it again (e.g. Safari) until
they're quit. I suspect a more liberal use of localised
autorelease pools would do wonders. But I've never tested this,
since I don't develop programs which are susceptible to such
problems. Anyone out there with a large Cocoa app that can shed
some [empirical] light on this?
I would not expect autorelease pools to be related to any such
problems. Without knowing more about your particular observation, it
sounds to me more like the effect of deliberate caching than any sort
of leak, and autorelease pools could of course not "fix" that.
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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