oshii

I've been searching for hours and couldn't find good general advice on how to reduce CPU load.

I know that GUI objects are huge consumers, but apart from that should I look for something else?

Also is there a way to measure this by myself? I found a time benchmark time patch (not sure about its creator, but I think it could be Chris Muir), which measures some time, however I'm not sure about some reference ranges, and is it actually the best one?

loadbang

message

comment

flonum

button

outlet

patcherargs

cpuclock

inlet

Hi guys,
I've been searching for hours and couldn't find good general advice on how to reduce CPU load.
I know that GUI objects are huge consumers, but apart from that should I look for something else?
Also is there a way to measure this by myself? I found a time benchmark time patch (not sure about its creator, but I think it could be Chris Muir), which measures some time, however I'm not sure about some reference ranges, and is it actually the best one? 

Hi guys,
I've been searching for hours and couldn't find good general advice on how to reduce CPU load.
I know that GUI objects are huge con

general-tips-for-reducing-cpu-load

i am not an expert for this low level stuff, but i think that for scheduler rate data, measuring how long they take to be processed by the objects above the target point is perfectly describing the "CPU requirement" of the algorithms.

and it is that what you usually want to know: if something still runs fine 

i am not an expert for this low level stuff, but i think that for scheduler rate data, measuring how long they take to be processed by the objects above the target point is perfectly describing the "CPU requirement" of the algorithms. 

and it is  that what you usually want to know: if something still runs fine  within its thread. 

1) I was basically asking for some general advice on how to reduce CPU load, not something too low level. I've got couple of patches which quite easily hit the 100% load every now and then, and would like to fix that. 

2) As a result the benchmark showed 5.5ms for a meter~ vs 3.3ms for a simple message object, and 2.1 for a number~, which I thought was supposed to be heavier than [message].

1) I was basically asking for some general advice on how to reduce CPU load, not something too low level.  I've got couple of patches which quite easily hit the 100% load every now and then, and would like to fix that. 
2) As a result the benchmark showed 5.5ms for a meter~ vs 3.3ms for a simple message object, and 2.1 for a number~, which I thought was supposed to be heavier than [message].
I am confused.

There's tons of other stuff you can be looking at before you start looking at the scheduler and UI objects. It's good practice to limit those, but where you will be spending big % will be on audio processes.

In the "View" menu there is a "Show CPU Usage" option. Turn that on and take a look at your patch. Also, when you turn it off, it prints off what % of your total CPU is being used by each individual object, and lets you double-click to go to that object.

That will help you identify your problem areas.

From there, it varies by what you're are doing (seeing a patch helps), but you normally want to disable parts of your patch that aren't presently in use. This normally happens by wrapping it inside a [poly~] object, and turning it on/off that way. But again, this varies a ton by what you're doing.

ya, that patch was done by Chris Muir long ago(one of my favorites :D)

it doesn't help for testing signal objects like meter~ and number~, though(meter~ takes more time mainly because it has to draw something to the screen, this will be in a lower-priority thread)... when you run the patch with number~, it is only testing how fast it takes input(number~ updates its right-outlet at a constant millisecond rate set within its inspector, this implies there's a scheduler-rate operation going on internally, this part of its operation can't be tested with Chris Muir's patch very accurately)... whereas 'message' is attempting to output something as soon as you give input to its left-inlet. also, even if you could test signal-rate objects alongside event-rate objects with that same patch, signals and events are processed in different threads(with different priority), as Roman was pointing out, so you'd still be comparing apples to oranges for the most part.

if you're working with mainly audio, most of what you'll want to do to reduce CPU load would probably be found with using poly~ to section off signal-processing in different parts of your patch and make them inactive when not in use, or figure out better algorithms in general(for example, i gave you a starting-point for harmonic distortion of an aural-exciter awhile back, and i was using MC objects there because they are new to me and i was excited to try them out, but a more efficient way to do that same thing would be to use the 'fffb~' object with "H" for its frequency-multiplier argument and only create the amount of harmonics you need to make an audible difference... learning small little tweaks like this can make a big difference.... btw, sorry if i misled you, just figured i'd demonstrate that idea while learning MC for myself as well :D)

slight tangent, but i think it would be very helpful for you, and it does have information on basic use of poly~, these tutorials by Peter Elsea are a really beautiful resource for getting to know the ins and outs of Max/MSP/Jitter, and if you learn much of what's here, you'll automatically be able to think about more efficient ways to do what you want to do:

Edit: haha, sorry, i didn't see Rodrigo's response before i posted mine, he said it much better than i could :D

ya, that patch was done by Chris Muir long ago(one of my favorites :D)
it doesn't help for testing signal objects like meter~ and number~, though(meter~ takes more time mainly because it has to draw something to the screen, this will be in a lower-priority thread)... when you run the patch with number~, it is only testing how fast it takes input(number~ updates its right-outlet at a constant millisecond rate set within its inspector, this implies there's a scheduler-rate operation going on internally, this part of its operation can't be tested with Chris Muir's patch very accurately)... whereas 'message' is attempting to output something as soon as you give input to its left-inlet. also, even if you could test signal-rate objects alongside event-rate objects with that same patch, signals and events are processed in different threads(with different priority), as Roman was pointing out, so you'd still be comparing apples to oranges for the most part.

if you're working with mainly audio, most of what you'll want to do to reduce CPU load would probably be found with using poly~ to section off signal-processing in different parts of your patch and make them inactive when not in use, or figure out better algorithms in general(for example, i gave you a starting-point for harmonic distortion of an aural-exciter awhile back, and i was using MC objects there because they are new to me and i was excited to try them out, but a more efficient way to do that same thing would be to use the 'fffb~' object with "H" for its frequency-multiplier argument and only create the amount of harmonics you need to make an audible difference... learning small little tweaks like this can make a big difference.... btw, sorry if i misled you, just figured i'd demonstrate that idea while learning MC for myself as well :D)

slight tangent, but i think it would be very helpful for you, and it does have information on basic use of poly~, these tutorials by Peter Elsea are a really beautiful resource for getting to know the ins and outs of Max/MSP/Jitter, and if you learn much of what's here, you'll automatically be able to think about more efficient ways to do what you want to do:
http://peterelsea.com/maxtutorials.html

Edit: haha, sorry, i didn't see Rodrigo's response before i posted mine, he said it much better than i could :D


Thanks Rodrigo, pretty good advice to use the CPU Usage. I was using the DSP CPU Monitor found in Extras, but it didn't show me such information. You said that once I turn CPU Usage off I should be able to see exactly what % is used by each individual object, but I can't see that. Can you please share a screenshot?

It will be in the Max window, which may be hidden or closed.

Here is a screenshot of a relatively simple patch:

Screenshot 2018-11-20 at 7.43.39 pm.png

It's worth noting that the percentage that it lists for each object is of the total listed at the top.

So in this case my average audio usage is 0.79%, of which the object [karma~] is 72% of.

Here is a screenshot of a relatively simple patch:


Hi Raja, again plenty of interesting information to consider from your side. I realise that I find the work with poly~ cumbersome and usually that's my last resort (i know.. i have to start loving it for its benefits, and yet..). 

However I'm not sure if this would help in my case - it's about a synth I'm building, consisting of 3 oscillators, each having a choice of waveforms - sine, triangle, square etc + custom wave, for which i was using multislider with 512 sliders, peek~ and a buffer~. Unfortunately I see that the combination of these 3 objects results in pretty huge CPU load (as per the benchmark) - 5000msec! So I had to remove that option from the first two OSCs and leave it only for the third one.

Hi Raja, again plenty of interesting information to consider from your side. I realise that I find the work with poly~ cumbersome and usually that's my last resort (i know.. i have to start loving it for its benefits, and yet..). 
However I'm not sure if this would help in my case - it's about a synth I'm building, consisting of 3 oscillators, each having a choice of waveforms - sine, triangle, square etc + custom wave, for which i was using multislider with 512 sliders, peek~ and a buffer~. Unfortunately I see that the combination of these 3 objects results in pretty huge CPU load (as per the benchmark) - 5000msec! So I had to remove that option from the first two OSCs and leave it only for the third one.

hmmm.... that can be an expensive operation, but it should only cause CPU to spike whenever you draw within the multislider only(unless you're causing it to be triggered constantly/repeatedly when it's not necessary), also, you can put a 'deferlow' object after the multislider(or if you're using 'uzi' after multislider to target sample-indices through peek~ try putting 'deferlow' between uzi and peek~), this might help as it will defer its output to a lower-priority thread.... it might also cause buffer~ to take longer to update to the custom waveform but at least you'll be able to focus your patch's processing on other things while it waits to draw. if you'd like, post the patch, we can take a closer look for you, otherwise, definitely take a look at the 'deferlow' object.

for which i was using multislider with 512 sliders, peek~ and a buffer~

 CPU"(seems like that's not referring to the 0.79% of 

 cpu because of the wording "total" vs. "average") are you sure of this? (i never knew this 😄 good to know)

hmmmm... but it says "72.2% of total CPU"(seems like that's not referring to the 0.79% of average cpu because of the wording "total" vs. "average") are you sure of this? (i never knew this 😄 good to know)

Yeah it's not very clear, but I've deduced it after seeing many patches like this one (there's no way that karma~ is using 72% of the total CPU!).

(i don't think it would be either, saw the benchmarks in XCode awhile back so that makes sense), 

i'm gonna use this utility in Max more often 😃

there's no way that karma~ is using 72% of the total CPU!

haha, cool, 
(i don't think it would be either, saw the benchmarks in XCode awhile back so that makes sense), 
i'm gonna use this utility in Max more often 😃

It's particularly nice as it jumps you to the object (like a normal error report), so when it says "poly~", you know which one.

The CPU usage percentage list (broken down by object) mentioned and screenshotted by {the amazing} Rodrigo, appears for me *after* I close my M4L patch.

Hi everyone - I can't seem to access this CPU usage list... I have selected it on the patch I want to show, and have the max console up, but nothing coming up. Any ideas? Thanks in advance.

Hi everyone - I can't seem to access this CPU usage list... I have selected it on the patch I want to show, and have the max console up, but nothing coming up. Any ideas? Thanks in advance.
On Max 8.1.3...

Wow. Had no idea the show cpu setting printed a list to the console - awesome! Is there any way to get a more granular breakdown of stuff going on inside a poly~? Setting show cpu on the window I get when I double click a poly~ does nothing

Is the CPU usage feature only visible when using standalone Max, or is it visible in Max for Live as well? I ask because I can only get it to work when I open a .maxpat and not a .amx.

whats the recommended CPU for Max 8? I have a Ryzen 9 5900x, but if I require a 5950x I can buy it asap. Just tell me.

general tips for reducing CPU load