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.

Thanks.

: )

IMHO you should find and isolate the CPU bottleneck of your patch : trial and error or using a profiler tool (like Shark) for more advanced user ; i do not think that you will save anything significant in “s/r vs cords” substitutions.

On mac with Monitor.app you can see RAM used by process ; do you fill all your available RAM ?

((My everyday tools are “Shark” application and “Top” command in the terminal.))

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?

This kind of trick seems complex ; isn’t it possible to use “pattr” behavior instead of ?
Each time i want to by-pass the “normal” behavior of maxMSP i get a very bad surprise later with thread/priority artefact.

My 2 cents.