Re: Working set bloat in Xcode 2
Re: Working set bloat in Xcode 2
- Subject: Re: Working set bloat in Xcode 2
- From: Nicko van Someren <email@hidden>
- Date: Wed, 25 May 2005 11:54:07 +0100
On 25 May 2005, at 7:02, j o a r wrote:
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?
Yes. My system is showing hardly any free memory. The Activity
Monitor tells me how many page ins and page outs the VM system has
performed and switching application causes these numbers to rise
dramatically (bringing up Dashboard for the first time in about 15
minutes needed over 2000 page-ins).
Is it not possible that it's something else, like for example
Spotlight indexing?
There is that too but no, the particular problem, as originally
stated, is that all my applications seem to be calling on larger
working sets than I remember seeing under 10.3.
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!
Hey, if I was guessing I would have written "my lap top seems to be
spending", not "my laptop IS spending". The paging stats indicate
that this is not just some subjective assessment, despite the fact
that on a subjective level the machine has been running very slowly
since installing 10.4.
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.
I'll give ObjectAlloc another go but unfortunately now that I've been
sucked in by Apple's marketing I don't have easy access to a machine
running Panther any more! I don't have enough spare hardware to keep
machines hanging around with old software.
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.
Yes, the documented behaviour of processing auto-release pools every
event loop turn seems to still be the case. What my programs seem to
be seeing is more to do with the more of the application data being
looked at and considered to be in the working set, possibly in
combination with various bits of Cocoa simply having more and larger
objects in use.
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.
I think in the case of Safari it is more a change in caching strategy
than an outright memory leak, but to a first order approximation they
look like the same thing!
Cheers,
Nicko
_______________________________________________
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