real memory usage - is this even possible?

  • Hi,

    I have a CoreData application that when a new volume is mounted iterates through its file and folder structure and creates an entity for each item, thus the contents can be represented as a browsable data source in an outline view.

    The cataloging process is handled in a seperate thread that has an own NSAutoreleasePool set up, at the end the NSThread is exited properly. Anything I alloc init in the thread receives a proper release message except for those flagged with autorelease.

    Running the app through MallocDebug reveals no memory leaks whatsoever, so I believe the code handles stuff properly.

    But the strangeness happens in observing the application in Activity Viewer. Mounting a disc image that has several thousand files the REAL MEMORY usage gradually jumps to some 80 MB, with virtula memory growing to 350 or so. And after the function is done and the autorelease pool is released, the thread is exited, the REAL memory does not go down.

    Now the interesting thing however is that when I observe the Wired and Active memory of the system memory in Activity Viewer, the combined value of them only grows about 1-2 Megs max, and I am not sure if all of that is attributable to my app.

    The Inactive part of course grows, and the free part shrinks, but to my knowledge the Inactive part is basically freed to, but is still in memory sorta like cached.

    So my question is, should I be concerned with what Activity Viewer is reporting, or is everything working out fine?

    Thanks,
    Ben
  • What you've discovered is that after allocating and freeing many small
    objects, malloc does not always free its pools. This is normal and
    nothing to be alarmed about.

    Internally, malloc is asking the VM system for big slabs of memory, and
    then doling out tiny pieces of these slabs to your app. One tricky bit
    is that if there is /even one little allocation/ left active in that big
    slab, 'free' can't release the slab; it has to keep the whole thing
    around. It's likely that, since using AppKit involves so many thousands
    of tiny (albeit typically short-lived) objects, you end up with a few
    tiny objects in each slab, surrounded by tons of "unused" space.

    It's not ideal---the VM system will page in/out the whole slab,
    regardless of the fact that 99% of it is just cruft data. But it's
    normal for an allocation system like this. Nothing to be concerned about.

    Benjamin Salanki wrote:
    > Hi,
    >
    > I have a CoreData application that when a new volume is mounted iterates through its file and folder structure and creates an entity for each item, thus the contents can be represented as a browsable data source in an outline view.
    >
    > The cataloging process is handled in a seperate thread that has an own NSAutoreleasePool set up, at the end the NSThread is exited properly. Anything I alloc init in the thread receives a proper release message except for those flagged with autorelease.
    >
    > Running the app through MallocDebug reveals no memory leaks whatsoever, so I believe the code handles stuff properly.
    >
    > But the strangeness happens in observing the application in Activity Viewer. Mounting a disc image that has several thousand files the REAL MEMORY usage gradually jumps to some 80 MB, with virtula memory growing to 350 or so. And after the function is done and the autorelease pool is released, the thread is exited, the REAL memory does not go down.
    >
    > Now the interesting thing however is that when I observe the Wired and Active memory of the system memory in Activity Viewer, the combined value of them only grows about 1-2 Megs max, and I am not sure if all of that is attributable to my app.
    >
    > The Inactive part of course grows, and the free part shrinks, but to my knowledge the Inactive part is basically freed to, but is still in memory sorta like cached.
    >
    > So my question is, should I be concerned with what Activity Viewer is reporting, or is everything working out fine?
    >
    > Thanks,
    > Ben
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<jstiles...>
    >
    > This email sent to <jstiles...>
    >
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today