Large Max patches = RAM hogs?

    Jun 22 2011 | 10:18 pm
    First off, I am not the most proficient of Max programmers, so please take it easy on me.
    I have a fairly large patch (~100MB). It is not doing any audio at all, just simple midi and some OSC handling. When checking the performance of the patch, to my surprise I discovered that it uses a significant amount of RAM >~750MB physical and >1GB virtual!!!
    I contacted support about this and they told me that removing any graphical interface objects (sliders, etc), would help. I have gone ahead and removed most of the slider and buttons, but still, RAM usage only dropped ~30MB.
    Do you guys find that with large projects, Max uses a lot of RAM? Do you have any advice for improving performance? Are there any particular objects which I should avoid? What techniques help with RAM management?
    Thanks in advance.

    • Jun 23 2011 | 11:20 pm
      not sure, I think the RAM issue is more about what files you might be using like video or audio that are put into RAM (like buffer~ instead of sfplay~, or using "loadram" to
      Objects to avoid, well, it would be great to get a list of guidelines for that, for sure. Some functions/filters/FX are a lot more CPU-intensive than others, don't know how the RAM factors into this.
      A 100 MB patch sounds totally biggest ever (well, I thought it was big :) was only about 5 MB. You can rack up a lot of MB by having embedded images, but most of the other objects are really quite small...not sure how you're getting to that rather massive size?
    • Jun 23 2011 | 11:35 pm
      a 100 mb patch? biggest ever! :). there is probably something wrong with it, for example you might have included picture files unintended or something like that. you also might need to learn how to build and use abstractions.
      i have never found maxmsp to use much RAM. the only problam with RAM can be that when you open and close hundreds of big patches with namespaces it can make your machine slower after a while because those will remain in RAM after you close the patch.that can also happen to audio buffers, under circumstances.
      the only thing what requires noticable amounts of RAM should be audio, video and GUI stuff (when bigger, uncompressed pictures files come to play)
    • Jun 24 2011 | 12:10 am
      Roman: I have been paid to work on a patch considerably larger than 100Mb, and Gyre, my step-sequencer on steroids weighs in at about 75 Mb.
    • Jun 25 2011 | 10:15 pm
      As far as I can tell, there are no audio files,no image files, and no videos used in the patch. I used to have lots of sliders and buttons, but I got rid of them. The size of the patch has not decreased much and the RAM usage has dropped only ~30-40MB.
      The most used objects are quite simple, nothing fancy at all. Lots of MIDI In and Out objects (both note and ctl), message objects, gate, route, send and receive, etc. Quite simple bread and butter type of stuff, actually.
      There are a lot of subpatchers within the main patch. Not sure if that has an impact. Also, I must learn about abstraction, but I am not sure how it is going to help with the RAM usage.
      @ Chris: out of curiosity, how much RAM does your Gyre step sequencer use?
      Thanks to all for your inputs.
    • Jun 28 2011 | 9:09 am
      I'm not sure how I would go about measuring such a thing to any degree of accuracy. A fresh launch of Max, with no patcher open gives me 42.9 MB Real, 1.01 GB Virtual. With Gyre loaded, I have 451.4 MB Real, 1.42 GB Virtual.
      This was using Activity Monitor.
      Note that some parts of Gyre are only loaded when requested, so these numbers are probably down a little from where they could be.
    • Jun 28 2011 | 1:45 pm
      Just curious, I have some patches that I know I could optimize. What is a good object so substitute for the gain~ slider? I mostly use gain~ to make things louder and don't actually ever use the slider. There must me a more basic way to make things louder. thanks
    • Jun 28 2011 | 2:18 pm
      is this what you mean?
    • Jun 29 2011 | 12:17 am
      Yeah that's what I mean Grizzle, Thank you. I've tried that before and it always seems that gain~ slider is louder than the *~ object at 1. Maybe it's just my imagination. I'll try that out. thanks.
    • Jun 29 2011 | 12:30 am
      The gain~ slider has about 20 db of gain. 0 db on the gain~ slider is at 127, and it goes to 150-something.
    • Apr 29 2016 | 6:45 pm
      I've been having this issue as well. Including all the poly~ instances and abstractions my patch amounts to probably about 150 MB, but by the time Max starts up its already using 3 to 4 GB of RAM. And that's BEFORE I load any VSTs or drum samples. When that happens I watch it jump another couple gigabytes, which is totally unreasonable considering the size of what I'm loading. Even if I preload every drum sample on my computer that's only maybe 300 MB and all the VSTs I use combined shouldn't amount to more than half a gigabyte. I'm getting to the point where I'm running out of memory on my computer.
      I'm curious about something Roman said up there about namespaces accumulating even after you close the patch. What exactly is a namespace? Under what circumstances can this also happen with audio buffers?
      I dismissed it as impossible, but I have had the uncanny feeling that every time I load my patch it's using up more memory than the last time, as if it's somehow accumulating, even if I close Max entirely and even if I restart my computer. Is this somehow possible?
    • May 02 2016 | 1:57 am
      I seem to have discovered something fundamental about the way Max operates. Any patch you open takes up on the order of 50x the space in memory as it does on disk. So if you have 100+ MB of actual code, you're looking at multiple GB of RAM used right from the start. Which sucks. Can anyone else confirm that this is how it works for them as well? Would compiling to a standalone maybe get around this?