A couple general questions about performance
Ahoy all. Pretty new to max, and my first sizable patch is getting pretty choppy. It starts off great, but as I use it it gets laggy fast. The macbook pro I'm using is almost brand new, and activity monitor doesn't show much of a strain at all on the CPU or memory. I just wanted to ask - is this typical? Is it common for max's performance to be pretty independent of how hard Activity Monitor says your machine is working? Seems like it'd just use more resources if it was struggling.
Happy to post my patch or go into great detail if anybody so desires, but I'll just say at this point that it's using groove~, a few basic effects, and jit.gl.text3d.
Thanks.
i have last macbook pro retina icore7 2,4 16 gb ram
also when edit patch everything go slow
i go to see cpu and ram usage but is normal
some help ??
Cut down all the gui items that you can. Message boxes being filled real time, Float integer boxes etc... Too many of these can really bog down your system, try checking the rendering order of your jit.gl.text 3d object.
See how it works if you make your render context smaller eg. instead of 800 x 600 try 640 x 480.
theres lots of optimisation tips here on the forums :)
example would help a lot.
Interested in this month-old post, as I too am trying to have a big patch more reactive and less CPU-Hungry.
@Andro: I've read here: https://cycling74.com/forums/ui-objects-and-efficient-coding/ that if GUI elements (and i suppose as well messages and reference int/float/toggle) are not visible than they are not actually taking any CPU processes.
Now, what if I have a loot of those reference messages, ints, floats, toggles, and sliders BUT they are not visible? I guess no extra CPU process should be involved... right?
This is very important to know, I guess, because sometimes those indicators are quite handy... and I actually, at this very moment, don not know if I should just get rid of them, or leave them running/not running in the background.
Do someone has any additional hint on this?
Thanks!
Well even if there not being drawn the process is still being calculated.
Try starting to learn the objects like coll and dict. They allow you to process huge amounts of lists, combine these with the zl objects and you can make a far more efficient system for processing large amounts of data.
A typical program you use has very little gui objects, try implementing this same design philosophy into your patches.
AFAIK, when GUi objects are not visibile, they don't stress the CPU, but they still affect the framerate (if you're working with Jitter) because, as Andro said, the process is still being calculated in the order your objects are.
well, it does make sense ;-)
Sooo, what do you think of a good compromise between debugging and performance?
I usually work changing variables of my max "application", which do not permit - I assume - debugging modes.
A good compromise - i guess - would be a Global Variable to open the gate of those messages, int, sliders.
This way I might have the patch running with or without those infos.
And actually see the CPU changes with and without the gate opened.
This is my take: do you perhaps have a better idea to maintain this kind of flexibility?