first thing would probably be to remove all numberboxes, toggles, graphical gates, bangs etc. (graphical elements) that are great for patching and testing but don't really serve a purpose in the finished patch. They need to redraw and eat a lot of CPU. Hiding them doesn't do you any good. GET RID OF THEM!!!

re loadbangs: depending on how you use your multiple loadbangs you might run into trouble. If I remember correctly, there is no guarantee in which order the loadbangs are going to fire. So if you have a specific order in which your patch is instantiated, ONE loadbang with trigger is probably the reliable way to go.

Yeah removing graphical objects that are not necessary is a good step...what about moving things into [patchers]?

MIB wrote on Fri, 03 July 2009 05:42If I remember correctly, there is no guarantee in which order the loadbangs are going to fire.

My experience is that they fire bottom-up, reliably. But note that "bottom-up" where subpatchers is concerned is affected by the stacking order of the subpatchers in their parent.

Optimization (for non-audio objects):

Every object counts. Some objects use more CPU than others. Graphical objects are especially CPU-intensive due to redraw, get rid of them if they're not used for the UI.

Printing to the Max window is expensive.

Every connection that a message will pass through counts. Don't connect objects to others that will only do something with the message occasionally, if possible.

Test variations of algorithms with uzi and timer, averaging over large numbers of iterations to determine the most efficient version (or objects used).

Avoid structures like cascaded split objects if possible.

If you are storing integers, bag, table and funbuff are more efficient than coll, especially when the size gets larger.

Use << and >> rather than multiplying or dividing by powers of two.

Combining math objects into one expr object can be useful if the math operation requires more than a couple of objects.

I have a question.. does this CPU/redraw overhead come in to play when using a message that doesn't change the display of the GUI object?

An example would be the fetch message and multislider. I alwayswonder if I would be better off storing the multislider data elsewhere rather than using fetch $1.

Graphical objects kill me. I am using [tab] and I have quite alot of interface and graphic objects in each tab. Switching tabs will cause max to freeze for 1-30 seconds sometimes. Hate it

Nick Inhofe wrote on Fri, 03 July 2009 03:19I have a question.. does this CPU/redraw overhead come in to play when using a message that doesn't change the display of the GUI object?

that depends wether a GUI object redraws when it receives a 0.77 when it is already at 0.77 or not.

i *think* they all do - but putting a [change] in front of them is also not for free.

one addition from me to the above list of tips:

- especially problematic is sending data to GUI objects which is high priority, such as data coming from a [metro].

i often use this:

[metro] | whatever | [t f f]___target | [defer] | [prepend set 1] | multislider | target

-110

Great! this is a useful thread.

One thing I find myself doing is having to connect a bang to the left input of every math object so it triggers when the right input is updated.

Nick Inhofe wrote on Fri, 03 July 2009 03:19does this CPU/redraw overhead come in to play when using a message that doesn't change the display of the GUI object?

An example would be the fetch message and multislider. I alwayswonder if I would be better off storing the multislider data elsewhere rather than using fetch $1.

Probably not, but there is no hard-and-fast rule. It depends on how the UI object is implemented.

In the case of multislider, only the CNMAT guys (and whoever has taken over maintenance... ej?) know for sure.

One thing though: with most UI objects it is a pretty safe bet that sending a value equal to the current value *does* trigger an update (redraw). So don't think something like [metro 0.5] -> [message box with constant list] -> [table/slider/multislider] is "safe" because you're "not really changing the value". With most objects you'll probably trigger a lot of redraw.

Peter Castine wrote on Sat, 04 July 2009 16:50In the case of multislider, only the CNMAT guys (and whoever has taken over maintenance... ej?) know for sure.

multislider doesn't ask for redraw when receiving a fetch message.

The freezing up with [tab] sounds like some other problem, I've never noticed this in my setup. This isn't a result from the GUI "expensiveness" for the CPU, which would be very small (yet a legitimate question regarding optimization). This is way over the top... don't know what's happening to make things freeze for this long. You said you have a lot of interface and graphic objects "in" each tab? So when you switch tabs, it switches all these graphics?

For the multislider/fetch question by Nick, I'd say if you don't need the interactive features of multislider, store it differently like with [zl reg] and get the values with [zl nth]. I don't know how you're making the list though, maybe you need the multislider, in which case you still may want to use [zl reg], but this might just add more expense.

Though with EJ's post about fetch not asking for a redraw, maybe you're fine. multislider is so handy it may be worth it.

Thanks to everyone for the info and the good discussion on the issue.. and please carry on! It's these little bits of insider info that make the forum worthwhile, among other things.

seejayjames wrote on Sat, 04 July 2009 13:31The freezing up with [tab] sounds like some other problem, I've never noticed this in my setup. This isn't a result from the GUI "expensiveness" for the CPU, which would be very small (yet a legitimate question regarding optimization). This is way over the top... don't know what's happening to make things freeze for this long. You said you have a lot of interface and graphic objects "in" each tab? So when you switch tabs, it switches all these graphics?

This is the interface: http://www.youtube.com/watch?v=T_m4MMn0iUE

Sometimes when switching from one tab to the other MAX will stall for a long time...audio will drop our or pause, etc...Alone, each module works fine. The only problem arises when switching tabs. You can see at 1:40 in that it lags going from Weather to Music...this time the lag was minimal, but sometimes it will hang max..

In that case, it also depends on how you display/hide objects. Do you use a large bpatcher, and send different offsets with [tab]? Or do you script objects to hide/show? Or something else? J-F.

Jean-Francois Charles wrote on Sat, 04 July 2009 21:57In that case, it also depends on how you display/hide objects. Do you use a large bpatcher, and send different offsets with [tab]? Or do you script objects to hide/show? Or something else? J-F.

bpatcher with offsets. No good?

marcoskohler wrote on Sun, 05 July 2009 04:19Jean-Francois Charles wrote on Sat, 04 July 2009 21:57In that case, it also depends on how you display/hide objects. Do you use a large bpatcher, and send different offsets with [tab]? Or do you script objects to hide/show? Or something else? J-F.

bpatcher with offsets. No good?

in theory thats good.

but i also had trouble with GUI initialisation in big bpatchers before, where stuff which was hidden did not initialise.

hide/show or offsetting bpatchers should be about the same.

Since you have a large UI, it could be worth trying another thing: to have the patches in different windows (no border, no menu), and to bring the useful window on top when you click on the corresponding tab item. You would open all windows when you open your patch, and give them the correct aspect and position (expect long load time), using the tab to bring a window on top. Note that it's been years I haven't used this technique: I don't know how efficient it would be. Jean-Francois.