Documentation on RAM usage in Max Msp

    May 20 2012 | 6:54 pm
    I've recently been working with larger and larger patches and I am finding that my computer is not responding as quickly as I desire.
    I'd like to know if there are answers to an RAM related questions I may have in any form of documentation, such as:
    Is it less CPU intensive to use patch cords, or [s]/[r] pairs?
    Is scripting with JS actually less cpu intensive than scripting via [thispatcher], and if so, by how much?
    If I am trying to change an object's attribute dynamically with a message connected to its inlet with a patch cord (such as varname $1), is it lighter on my computer to have the patch cord permanently connected to the object or to connect it dynamically when I select the object (via [hover]/[mousestate], etc?) ... Especially if I am working with hundreds of objects at once.
    These are just examples.
    Is the only option to literally monitor my task manager for fluctuations of memory and cpu usage? I'd love to have some sort of guideline when it comes to better ways of dealing with ram.
    : )

    • May 23 2012 | 10:36 am
      I guess not...
    • May 19 2016 | 1:43 pm
      Hi Goingdeaf, did you ever found a good way to measure RAM usage? And did you find more info on what eats up the most RAM in patches?
      Having similar problems here with a big m4l device.
    • May 19 2016 | 5:55 pm
      Gui elements hog resources, if you can replace a float box with the f object , int boxes with the int object(no numerical display) and message boxes with pak or pack this could save you a lot of system resources. Try dropping anything which needs to be redrawn heavily like jit.pwindow etc etc..
    • May 20 2016 | 9:13 pm
      @ANDRO thanks!
      But are you sure about the message boxes? I replaced hundreds of them (in abstractions) today, mostly things like [set $1] to [prepend set] or [100] to [t 100] and what happened was this:
      before the edit: 1 instance of my device: 15,4 sec load time. 350 mb ram.
      after the edit: 1 instance of my device: 17,8 sec load time. 60 mb ram.
      tried it 3 times, same result. then I restarted Live and I got this: 1 instance of my device: 16,4 sec load time. 350 mb ram.
      confusing! anyway, I'm afraid the last test result is more likely to be true.
      (measured the ram with osx activity monitor.)
    • May 21 2016 | 10:04 am
      A simple thing, have you tried running your patch in presentation mode with only the gui elements that you need ? This gives me all the speed back that I was missing with my patches. Also forgot to mention prepend ! I'm pretty sure message boxes uses more memory/gpu than prepend because you can click it which means it has to check if the object has changed graphically. I find checking RAM usage a fickle thing to get right, its not only RAM its how many threads your running the patch on, splitting some patches over separate instances (like 2 different max files) can sometimes help with increasing the speed of the patches. As always experimentation is the only way to find out.
    • May 21 2016 | 5:11 pm
      where prepend is not enough, pak does these jobs perfectly
      yet it is questionable that a bunch of data objects "suck CPU" in some way. you should be able to run 100,000s of them on a modern computer, and mabye a bit less in overdrive.