re: Leopard real amount of RAM used by application
re: Leopard real amount of RAM used by application
- Subject: re: Leopard real amount of RAM used by application
- From: Ben Trumbull <email@hidden>
- Date: Tue, 13 Nov 2007 13:14:57 -0800
Frank,
On Tiger I got the memory utilization down to around 128Mb during the
entire 60 minute run.
Now with Leopard, during the early stages memory utilization goes up
to 1GB and stays there during the entire processing.
That sounds like a bug, but it's hard to diagnose from your
description. If you can reproduce the problem in a sample project,
please file a report with bugreport.apple.com
Is this 1 Gb simply used because it's there and no other processes
need? will it go down again if Leopard needs the RAM?
No, not if you're doing most of your processing with Core Data. On
Tiger and Leopard, the memory usage with Core Data should be fairly
deterministic (what you do to yourself with threads is another
story). We don't automagically preheat any caches, we simply fetch
what you ask us.
So it could be a leak, it could be an autorelease pool moved and you
need another, or something else has gone awry.
What makes this a bit of a drag is that each test takes ages to
complete, so I want to avoid using instrumented code or a managed
execution environment if it's going to mean that the code takes 10
times longer.. surely there's a better way?
'heap' can provide some useful data, especially if your batch process
pauses at the end of an iteration. Presumably, you should have some
idea about what objects should still be live at the beginning of the
next iteration.
'leaks' is also handy, but only for a first pass. It's easy to use,
but suffers from many false negatives.
You could also check if there's any low hanging performance
optimizations with Shark or Instruments. If your test runs faster,
it may be easier to debug, or just nicer to use. And you might get
lucky and find it's slow because of the memory allocations, and get a
2:1
Instruments on Leopard has a Core Data template, and it will provide
events for particularly expensive operations (faults that incur I/O,
fetches, saves)
It's pretty easy to fire up Instruments, sample your app, and then go
"uhm, why is my code fetching from the database when the user breaths
on it ?" or "didn't already fetch all those objects ? Why is it
doing it again and again and ..."
The detail inspector in Instruments will give you a stack trace, so
you can see how notifications, KVO, or accessor methods go off and
trigger more work than you expected.
--
-Ben
_______________________________________________
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