re: Leopard real amount of RAM used by application

FROM : Ben Trumbull
DATE : Tue Nov 13 22:14:57 2007

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