polybuffer creates lots of Inactive Memory: is it leaking?

    Feb 27 2013 | 2:16 pm
    Reading a large number of samples generates an enormous amount of inactive memory (max 6.0.8 / osx 10.8.2 / 4GB mem).
    In the process, 416 sound files are loaded, which occupy 580MB disk space. Before starting, the inactive memory reads 142 MB. Upon completion it has gone up to 923 MB. With the purge command it goes down to 190 MB. Polybuffer at that point reports 768 MB of memory used. The two images show the before and after states.
    What to think of this?
    As an aside, instead of reading the content of the buffer in one go I have to read them one by one, if not max becomes unresponsive as long as it busy with this task.

    • Feb 27 2013 | 3:25 pm
      What is Max memory usage? Do you see it go down when you clear the polybuffer~?
    • Feb 27 2013 | 3:48 pm
      Some very strange nomenclature being used in that screenie there.
      What exactly does "inactive" memory mean in this context? Or, in fact . . . at all? The use of "wired" is also a bit weird - I suspect it refers to what we refer to as Commit Charge in NT-Land but is absolutely the wrong term if it is, AIUI.
      Is that OS X-native or a third-party tool?
    • Feb 27 2013 | 4:06 pm
      Three images attached. First is before loading sound files, second after, third after purging the ram. Clearing polybuffer~ does make the memory usage go back to the initial state, but does not clear the Inactive Memory.
    • Feb 27 2013 | 7:47 pm
      Yeah, as Chris pointed out, nothing to worry… I do a purge from time to time and that's not because of Max, the OS uses this inactive memory for whatever is "appropriate".
    • Feb 27 2013 | 9:43 pm
      The explaination @ support.apple makes perfect sense.
      The descriptors in Activity Mon . . . not so much.
      That said, the situation on Win is probably as confusing for users, so I'm not here to rip on OS X. Genuinely interested, as I'll be getting a Mac soon.
      @ Emmanuel:
      Does flushing the cache actually improve your use-case? Generally speaking this stuff is leave-it-the-fuck-alone stuff, the OS is smarter than thou etc . . . so I'm curious now about whether OS X has something bust about its memory management or caching that I ought to be concerned about bothering with manipulating these?
      Or do you have a genuine use-case where flushing measurably improves performance?
      TIA for any info you can provide.
    • Feb 28 2013 | 2:30 pm
      My usage of purge is just a convenience to not restart my computer. I would certainly not recommend doing that in realtime, the command takes an indefinite time to complete, and some freezing of the UI/audio occurs when doing it. In general, the OS keeps playing with this inactive memory to do its best, which is hopefully not too bad.
    • Mar 01 2013 | 7:50 am
      Thanks for the responses. I am working on an overhaul of an app where in the previous version all those files were loaded by instantiating so many buffers. I used poly~ for that. In that case the IM would not show any increase. So then it means polybuffer~ is more efficient :)
      I noticed the bas effects of purging. I will refrain from that, moreover because it is not necessary or desired.
    • Mar 01 2013 | 1:26 pm
      Well, I could be wrong because I'm unfamiliar with the specifics of everyones situation - but flushing the cache (or worse, as I saw on the forum here recently, dabbling with RAMdisks) strikes me as fighting OS mem management without much of an understanding of how or why the OS does the things it does.
      Inactive Memory, for instance, seems to correlate to what's called the "Standby List" in Win parlance . . . and probably behaves similarly in that it is immediately available for use when requested by an application.
      Fair enough, if you have a leaky process - then ya gotta do what ya gotta do.
      The subject piques my interest because as I said, I'll be getting a Mac at some point soon - and I've had to rescue many computers suffering the effects of "tweaks" related to a complete lack of understanding of virtual memory, ostensibly to improve DAW performance . . . not to imply I'm saying that is the case here. :)