maxista

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?

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!!! 

large-max-patches-ram-hogs

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 jit.qt.movie).

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 crazy...my 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?

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)

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)


Roman: I have been paid to work on a patch considerably larger than 100Mb, and 

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.


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?

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. 

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.

Note that some parts of Gyre are only loaded when requested, so these numbers are probably down a little from where they could be.

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.

Note that some parts of Gyre are only loaded when requested, so these numbers are probably down a little from where they could be.


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

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.

The gain~ slider has about 20 db of gain. 0 db on the gain~ slider is at 127, and it goes to 150-something.

The  gain~ slider has about 20 db of gain. 0 db on the gain~ slider is at 127, and it goes to 150-something.


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?

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?

Large Max patches = RAM hogs?