Sukandar Kartadinata

after having used Max for 25 years I feel a little embarassed to ask these questions, but over the last few years I've run into problems with CPU performance more often than I seem to remember. I'm not sure wether it's because previous projects were less demanding or if my expectations are kinda skewed for other reasons. Or maybe I simply missed some basics while Max evolved from v4 to 5 to 6 and now 7.

Anyway, I've attached a project were I tried to illustrate the behaviour that keeps irking me. It basically comes down to how much the GUI slows down the CPU. The patch happily does some random multi-voiced groove~ babble, requiring no more than 20% CPU (as observed in Activity Monitor), but as soon as I add some GUI objects it jumps up to 90%. Even 2 simple meter~ objects raise the load by 10%.

Just to be clear - this is not about having Overdrive enabled or not.

(plus, sometimes Max gets "stuck" at these 90% after disabling the GUI again, sometimes even after closing all patches. But I guess that's another story...)

And all that for a relatively simple patch. I'm currently working on some rather complex instruments for two local musicians and the GUI slows down Max to a point were I have to disable the sensor input (and not Audio!) whenever I want to move an object box around, as things become unbearably sluggish.

Alternatively I throttle the GUI by adjusting the refrehsrate scheduler parameter, but then not only does the GUI become painful to watch, but also the editing gets jerky. What's more is that at some point the event level processing itself becomes irregular, and it's not just about the missing eye candy but actually comes down to how things sound.

Maybe I've become spoiled over the years to have number boxes and faders everywhere and should simply pare things down to the stuff actually required while playing the instrument. However, to me GUI objects are not just about nice visualizations during a performance, but also necessary while developing and debugging the instrument and it's kinda annoying to constantly add&remove these readouts, as you think you've nailed down the abstraction so you can clean it up, only to discover an hour later that you need to change something because it's still buggy or needs an additional feature. Adding gate objects for each GUI readout to enable/disable debugging is kinda cumbersome too...

So to sum it up - one thing is that I'm simply puzzled how really basic GUI objects require so much CPU. Here, I'm kinda willing to concede that I'm just expecting too much. If that's the case though, I need some strategies how to make the development & debugging process a bit more bearable. E.g. one feature that might help could be a "CPU % Limit" parameter for the GUI similar to the one for Audio processing, so there's always some headroom to keep the editing responsive.

Or maybe I'm simply missing a magic adjustment in the scheduler preferences.

There, I typically leave all the defaults (except for the refreshrate as mentioned above).

Thanks for any suggestions - hope I made myself clear. If not, I'm happy to explain in more detail.

Hi everybody,
after having used Max for 25 years I feel a little embarassed to ask these questions, but over the last few years I've run into problems with CPU performance more often than I seem to remember. I'm not sure wether it's because previous projects were less demanding or if my expectations are kinda skewed for other reasons. Or maybe I simply missed some basics while Max evolved from v4 to 5 to 6 and now 7.

Anyway, I've attached a project were I tried to illustrate the behaviour that keeps irking me. It basically comes down to how much the GUI slows down the CPU. The patch happily does some random multi-voiced groove~ babble, requiring no more than 20% CPU (as observed in Activity Monitor), but as soon as I add some GUI objects it jumps up to 90%. Even 2 simple meter~ objects raise the load by 10%.
Just to be clear - this is not about having Overdrive enabled or not.
(plus, sometimes Max gets "stuck" at these 90% after disabling the GUI again, sometimes even after closing all patches. But I guess that's another story...)

And all that for a relatively simple patch. I'm currently working on some rather complex instruments for two local musicians and the GUI slows down Max to a point were I have to disable the sensor input (and not Audio!) whenever I want to move an object box around, as things become unbearably sluggish.
Alternatively I throttle the GUI by adjusting the refrehsrate scheduler parameter, but then not only does the GUI become painful to watch, but also the editing gets jerky. What's more is that at some point the event level processing itself becomes irregular, and it's not just about the missing eye candy but actually comes down to how things sound.

Or maybe I'm simply missing a magic adjustment in the scheduler preferences.
There, I typically leave all the defaults (except for the refreshrate as mentioned above).

Thanks for any suggestions - hope I made myself clear. If not, I'm happy to explain in more detail.
all best,
Sukandar


questions-regarding-cpu-requirements-of-audio-vs-events-vs-gui

Unfortunately I can't help you, but I will definitely join the discussion because I have the same question.

You have pasted a great patch for cpu testing. It would be nice if this patch would be optimized by someone more experienced and then posted as an example for the community. Of course I'm also interested what Scheduler settings would work in the given example.

You have pasted a great patch for cpu testing. It would be nice if  this patch would be optimized by someone more experienced and then posted as an example for the community. Of course I'm also interested what Scheduler settings would work in the given example.

Running your patch on Windows 10 Max 7.2.2 on an 8 core CPU @3.4Ghz and the CPU load never goes above 15%. Have you tried on another machine?

On another patch I had performance issues with (lots of GUI and list processing), raising Poll Throttle, Queue Throttle and Redraw Queue Throttle helped a lot. Sometimes Deferlow object can be a great ally!

Running your patch on Windows 10 Max 7.2.2 on an 8 core CPU @3.4Ghz and the CPU load never goes above 15%. Have you tried on another machine?
On another patch I had performance issues with (lots of GUI and list processing), raising Poll Throttle, Queue Throttle and Redraw Queue Throttle  helped a lot. Sometimes Deferlow object can be a great ally!


I made that to test cpu. Here MBpro 13" i7 2.8 GHz, MSP cpu 5 %, and Activity Monitor 106 %.

I had the same questions from Max 4 to Max 7, but what is Max, what is OSX ?

I made some modifs to your patches. "deferlow" seems the best way. Tryed "funnel" in place of "pack", and "s buf_size" in place of "v buf_size"

Hi Sukandar
I made that to test cpu. Here MBpro 13" i7 2.8 GHz, MSP cpu 5 %, and Activity Monitor 106 %.
I had the same questions from Max 4 to Max 7, but what is Max, what is OSX ?
I made some modifs to your patches. "deferlow" seems the best way. Tryed "funnel" in place of "pack", and "s buf_size" in place of "v buf_size"


- deferlow didn't change things much for me. Still goes up to 90% and beyond

- I increased the throttles by factors of 2, 5, 10, even 100 of their default value. No significant change either.

- Haven't tried a different machine yet. Will see if I can find a Windows box.

Same patch in Max5: 40% when enabling step (5), 60% when adding more GUI (step 7)

Will try Max4 over the weekend on my older MacBookPro

- older Max versions:
Same patch in Max5: 40% when enabling step (5), 60% when adding more GUI (step 7)
Same patch in Max6: 75%
Will try Max4 over the weekend on my older MacBookPro

Until Max 4 the graphical interface of Max was pixel based (and therefore really fast). Since Max 5 the interface is vector based and, I believe, based on a 3rd party cross-platform SDK. This approach takes of course more CPU and is probably not coded the most efficient.

There have been posts on the forum before about using a lower screen resolution then the retina resolution to partially overcome this:

https://cycling74.com/forums/retina-performance/

I have for example once mentioned that running two sonograms is seriously slowing down the responsiveness of the interface:

https://cycling74.com/forums/user-interface-becomes-slow-because-of-sonogram/

I believe improvements have been made in the recent versions of Max but the graphical interface still takes a lot of CPU.

There have been posts on the forum before about using a lower screen resolution then the retina resolution to partially overcome this:
https://cycling74.com/forums/retina-performance/

I have for example once mentioned that running two sonograms is seriously slowing down the responsiveness of the interface:
https://cycling74.com/forums/user-interface-becomes-slow-because-of-sonogram/ 

So a 3rd party GUI gets introduced, I guess to make the port to Windows easier that arrived with Max5.

I'm really curious now to test on a Windows Box to confirm hugobox' numbers.

It still doesn't fully explain why the Max5 GUI is so much faster than Max7.

I also suspected Retina-scaling, so I reduced my resolution to non-Retina (1440x900) and launched Max7 in lowres mode.

Hi Edwin,
thanks much for the background info.
So a 3rd party GUI gets introduced, I guess to make the port to Windows easier that arrived with Max5.
And Mac performance suffers. Great.
I'm really curious now to test on a Windows Box to confirm hugobox' numbers.

I also suspected Retina-scaling, so I reduced my resolution to non-Retina (1440x900) and launched Max7 in lowres mode.
I'm now slightly below 90% :/

Sukandar, same thing here for my modifs, and Activity Monitor uses more with, than your original patch...

I'm an old enduser, my diagnostic is symptomatic : thanks Erwin for the explanation.

I've had hard time with a MBpro i7 early 2011. A SSD inside helped a lot, but the motherboard dyed 2 months later. So I don't know exactly. Maybe an update system, maybe the mode of OSX to buffer and refresh the screen.

Hi all
Sukandar, same thing here for my modifs, and Activity Monitor uses more with, than your original patch...
I'm an old enduser, my diagnostic is symptomatic : thanks Erwin for the explanation.
I've had hard time with a MBpro i7 early 2011. A SSD inside helped a lot, but the motherboard dyed 2 months later. So I don't know exactly. Maybe an update system, maybe the mode of OSX to buffer and refresh the screen.
Thanks, i learned something
Best
Michel


On my old laptop (2008 MBP 2.4GHz Core 2 Duo, OS X 10.7.5) the numbers look just as bad, if not worse.

The baseline (i.e. w/o GUI) is higher in general at about 40%. Enabling the GUI brings it up to 100% (Max5) and 90% (Max6)

I forgot that the machine doesn't run Max4 with 10.7.5. I might try to find an older HD with 10.5.x.

When I run Max7 in a virtual machine (Fusion 8, Win10) on my main laptop the baseline is higher at 55%, but when I enable the GUI it's actually below 90%! (although it depends a bit on the window size of the VM and what parts of the patch are visible)

Haven't found a real Windows box yet, at least not a recent one.

Making the patcher window smaller, such that less GUI objects are visible, actually reduces the CPU load a lot.

However, dragging it to the bottom (again in order to make GUI objects invisible), does not. Neither does hiding the Max app, nor minimizing the patcher window.

Some more performance figures:
On my old laptop (2008 MBP 2.4GHz Core 2 Duo, OS X 10.7.5) the numbers look just as bad, if not worse.
The baseline (i.e. w/o GUI)  is higher in general at about 40%. Enabling the GUI brings it up to 100% (Max5) and 90% (Max6)
I forgot that the machine doesn't run Max4 with 10.7.5. I might try to find an older HD with 10.5.x.

When I  run Max7 in a virtual machine (Fusion 8, Win10) on my main laptop  the baseline is higher at 55%, but when I enable the GUI it's actually below 90%! (although it depends a bit on the window size of the VM and what parts of the patch are visible)
Haven't found a real Windows box yet, at least not a recent one.

Some additional notes:
Making the patcher window smaller, such that less GUI objects are visible, actually reduces the CPU load a lot.
However, dragging it to the bottom (again in order to make GUI objects invisible), does not. Neither does hiding the Max app, nor minimizing the patcher window.


However, dragging it to the bottom (again in order to make GUI objects invisible), does not. Neither does hiding the Max app, nor minimizing the patcher window."

- executing steps 1-5 => CPU load 90% as before

- dragging window down, so only the titlebar is visible => CPU load goes up to 110%!

- dragging window up => CPU load back to 90%

- executing steps 1-4 => CPU load 20% as before

- enabling only the top multislider => CPU load rises to 65%

- reducing the window size so that only the multislider is visible => CPU load goes down to 20%

Yes, the multislider is fully active as before, just the window is smaller!!

- reducing the window size even further to its absolute minimum => CPU load goes down to 12%

Yes, it goes down below the baseline where no GUI was active!!

- playing more with the window size it seems that CPU load scales linearly with it, even though the stuff that becomes hidden (e.g. the waveform~object) is not even active

Something is seriously wrong with that 3rd party cross-platform SDK...

(maybe it's a Raytracer that scales with pixel count)

Some additional notes:
Making the patcher window smaller, such that less GUI objects are visible, actually reduces the CPU load a lot.
However, dragging it to the bottom (again in order to make GUI objects invisible), does not. Neither does hiding the Max app, nor minimizing the patcher window."

It gets even weirder:
(1)
- executing steps 1-5 => CPU load 90% as before
- dragging window down, so only the titlebar is visible => CPU load goes up to 110%!
- dragging window up => CPU load back to 90%

(2)
- executing steps 1-4 => CPU load 20% as before
- enabling only the top multislider => CPU load rises to 65%
- reducing the window size so that only the multislider is visible => CPU load goes down to 20%
   Yes, the multislider is fully active as before, just the window is smaller!!
- reducing the window size even further to its absolute minimum => CPU load goes down to 12%
   Yes, it goes down below the baseline where no GUI was active!!
- playing more with the window size it seems that CPU load scales linearly with it, even though the stuff that becomes hidden (e.g. the waveform~object) is not even active

I don't get this
Something is seriously wrong with that 3rd party cross-platform SDK...
(maybe it's a Raytracer that scales with pixel count)


CPU load changes drastically when in edit mode.

Consider the patch attached, which is just a metro at a 5ms interval, a counter, and a number box - albeit in a larger than necessary window.

Once the metro is enabled, CPU load climbs to 15% (which already is ridiculous).

(maybe it's because it's Friday the 13th)

And another observation:
CPU load changes drastically when in edit mode.

Consider the patch attached, which is just a metro at a 5ms interval, a counter, and a number box - albeit in a larger than necessary window.
Once the metro is enabled, CPU load climbs to 15% (which already is ridiculous).
But in edit mode it climbs to 60%!

(maybe it's because it's Friday the 13th)


In the previous patch I noticed that the CPU load did not scale linearly with the size of the window, as before. Rather it jumped from15% to 60% when a certain size was reached. So, attached is another patch where I can remotely adjust the size of the window (I need to do it from another patch so I can change values while in edit mode)

I set the height to certain value and incremented the width until I saw the jump:

So it seems if there's more than ~240k pixels the CPU load jumps

So there seems to be an issue regarding some memory boundary/limitation.

Edit: this particular problem disappears in non-retina/low resolution mode

Yet another detail:
In the previous patch I noticed that the CPU load did not scale linearly with the size of the window, as before. Rather it jumped from15% to 60% when a certain size was reached. So, attached is another patch where I can remotely adjust the size of the window (I need to do it from another patch so I can change values while in edit mode)
I set the height to certain value and incremented the width until I saw the jump:
Height=360 - Jump at 671 to 672
Height=400 - Jump at 602 to 603
Height=500 - Jump at 479 to 480

So it seems if there's more than ~240k pixels the CPU load jumps
(with a 5ms metro; in edit mode)

So there seems to be an issue regarding some memory boundary/limitation.
Transfer to the GPU?

Edit: this particular problem disappears in non-retina/low resolution mode


No solutions, I'm afraid, but I'm adding myself to the list of people who would really like to know what's going on with this and if it's something that might at some point be improved (no comment from the guys at C74 yet, I notice).

I too have been struggling with this issue, with several work patches that have been in gradual development over many generations of Max, and which have become cpu hogs since Max6 and especially Max 7. After a recent posting on this, I was reminded about turning Retina mode off (which I think I forgot to do in the transition from v6 to v7), which, as you also found, at least brought the overall load back below the 100% mark. I will also try the window reducing you've discovered, although that's obviously less than ideal in a workshop or performance situation where one needs to have a quick overview of what's happening in a patch.

I'm also not sure what exactly the cpu monitor in Activity Monitor is telling me. I've seen it go a fair way over 100% and the computer is still running (though clunkily). So what is it actually telling me?! (How can you use more than 100% of anything?!)

No solutions, I'm afraid, but I'm adding myself to the list of people who would really like to know what's going on with this and if it's something that might at some point be improved (no comment from the guys at C74 yet, I notice).
I too have been struggling with this issue, with several work patches that have been in gradual development over many generations of Max, and which have become cpu hogs since Max6 and especially Max 7. After a recent posting on this, I was reminded about turning Retina mode off (which I think I forgot to do in the transition from v6 to v7), which, as you also found, at least brought the overall load back below the 100% mark. I will also try the window reducing you've discovered, although that's obviously less than ideal in a workshop or performance situation where one needs to have a quick overview of what's happening in a patch.
I'm also not sure what exactly the cpu monitor in Activity Monitor is telling me. I've seen it go a fair way over 100% and the computer is still running (though clunkily). So what is it actually telling me?! (How can you use more than 100% of anything?!)


I also noticed a few causes of serious increase in cpu load since updating to Max 7.2. I was able to reduce it as follows:

1. On initial load, I was getting long hangs when plot~ objects were attempting to render buffers that had not yet been loaded with data. The plot~ objects should not be sent a refer message until after the buffer is sized.

2. Snapshot~ objects cause hangs of a second or more if they are in a poly~ object which is unmuted while they are active. The snapshot~ objects must be stopped before the poly~ object is muted, and restarted at least one scheduler interval after the poly~ object is unmuted.

3. Rendering objects should not receive multiple messages for a different version of the same rendering operation in the same scheduler cycle. This used to be no problem, but now, in the above 'plot~' example, if the plot object receives two 'refer' messages with different startpoints in the same scheduler cycle, it hangs the machine for several seconds.

Otherwise generally, low-cost graphics processors are not designed for audio-rate updates in several manners. First, they do not have dedicated VRAM but use the main system DRAM. VRAM is the modern name for 'multiport memory..' Multiport memory is designed so that read operations for display at megapixel rate can occur simultaneously with read/write operations from main memory to the dedicated graphics memory. Low-cost graphics CPUs use the main system DRAM for video, which is much cheaper; but while the video processor is fetching data to display at megapixel rate, the CPu cannot write to that DRAM. Thus the most common cause of sluggish video is that the graphics driver is attempting to use the main CPU for vector rendering, which then has to be read pixel by pixel for rasterized graphics, and this cannot occur simultaneously in main memory, which causes sluggish behavior overall that is not related to the CPU demand at all. But VRAM has historically been much more expensive than main memory.

Second, just because a graphics card has vector rendering capability does not mean software actually uses it. There are many different APIs for graphics rendering, and there is never any guarantee that software is actually optimized for graphics performance unless it recommends a particular video graphics API. It takes extra work to port vector operations to a dedicated graphics accelerator, which only works for people who own it, and the commonly used APIs have been significantly changing every decade or so, so most developers outside the gaming community have not bothered in the past.

The good news for users is that Moore's law has been faltering, so that new architectures to exploit smaller semiconductor geometries are slowing. Also the expense of building a new graphics architecture is immense compared to 20 years ago, and so they are far less frequent. Hence one may expect over the next decade a convergence on more standardized APIs that will appear in more software with better vector drawing performance.

1. On initial load, I was getting long hangs when plot~ objects were attempting to render buffers that had not yet been loaded with data.  The plot~ objects should not be sent a refer message until after the buffer is sized. 

3. Rendering objects should not receive multiple messages for a different version of the same rendering  operation in the same scheduler cycle. This used to be no problem,  but now, in the above 'plot~' example, if the plot object receives two 'refer' messages with different startpoints in the same scheduler cycle, it hangs the machine for several seconds. 

Otherwise generally, low-cost graphics processors are not designed for audio-rate updates in several manners. First, they do not have dedicated VRAM but use the main system DRAM. VRAM is the modern name for 'multiport memory..' Multiport memory is designed so that read operations for display at megapixel rate can occur simultaneously with read/write operations from main memory to the dedicated graphics memory.  Low-cost graphics CPUs use the main system DRAM for video, which is much cheaper; but while the video processor is fetching data to display at megapixel rate, the CPu cannot write to that DRAM. Thus the most common cause of sluggish video is that the graphics driver is attempting to use the main CPU for vector rendering, which then has to be read pixel by pixel for rasterized graphics, and this cannot occur simultaneously in main memory, which causes sluggish behavior overall that is not related to the CPU demand at all. But VRAM has historically been much more expensive than main memory. 

Second, just because a graphics card has vector rendering  capability does not mean software actually uses it.  There are many different APIs for graphics rendering, and there is never any guarantee that software is actually optimized for graphics performance unless it recommends a particular video graphics API.  It takes extra work to port vector operations to a dedicated  graphics accelerator,  which only works for people who own it, and the commonly used APIs have been significantly changing every decade or so, so most developers outside the gaming community have not bothered in the past. 

The good news for users is that Moore's law has been faltering, so that new architectures to exploit  smaller semiconductor geometries are slowing. Also the expense of building a new graphics architecture is immense compared to  20 years ago, and so they are far less frequent. Hence one may expect over the next decade a convergence on more standardized APIs that will appear in more software with better vector drawing performance.


Me too ... I using Max since 15 years and I also notice big cpu jumps since the versions 6 and 7. I thought it was because my hardware is to old but now I have a new MacBookPro (2.9ghz 16GB 460) with a fast graphic chip. And the usage of the cpu is nearly the same, the graphic response ist still very laggy AND the cpu usage is jumping continuously somtimes between 10 and 39! This behaviour can't be normal!

Please C74 write a answer to the questions in this thread. I think there are many users they have this problems! And that is something essential when you want to program complex patches in max. We want understand this behaviour!

Me too ... I using Max since 15 years and I also notice big cpu jumps since the versions 6 and 7. I thought it was because my hardware is to old but now I have a new MacBookPro (2.9ghz 16GB 460) with a fast graphic chip. And the usage of the cpu is nearly the same, the graphic response ist still very laggy AND the cpu usage is jumping continuously somtimes between 10 and 39! This behaviour can't be normal!
Please C74 write a answer to the questions in this thread. I think there are many users they have this problems! And that is something essential when you want to program complex patches in max. We want understand this behaviour!
Thanks ...


what do you guys experience when you patch along and ignore that weird info?

i dont know it, but i bet they just changed the CPU meter settings.

in max 4 the CPU meter ONLY shows the SIGNAL stuff; which is pretty much what most people would like to know.

since max 7 it seems to show everything, and then it is no wonder that you get up to 90% for every little picture change or a gui object because, dont forget: that is peak not average! just as an audio meter is!

it somehow reminds me on my first experience with OSX... you moved a window = cpu goes to 100%... but other processes still run fine.

in max 4  the CPU meter ONLY shows the SIGNAL stuff; which is pretty much what most people would like to know.

it somehow reminds me on my first experience with OSX... you moved a window = cpu goes to 100%... but other processes still run fine.


can't go into all the details again (see my previous posts for that), but just wanted to remark that I was never talking about Max' own CPU meter, but the CPU load I see in Activity Monitor.

Also, as far as I'm concerned, it's not just obsessing about an abstract CPU% load number going up - I actually do have performance issues. The first stage is always that editing becomes jerky unless I disable the sensor input, and if I keep adding functionality event processing eventually degrades.

can't go into all the details again (see my previous posts for that), but just wanted to remark that I was never talking about Max' own CPU meter, but the CPU load I see in Activity Monitor.
Also, as far as I'm concerned, it's not just obsessing about an abstract CPU% load number going up - I actually do have performance issues. The first stage is always that editing becomes jerky unless I disable the sensor input, and if I keep adding functionality event processing eventually degrades.


sukander said "The first stage is always that editing becomes jerky "

Working on (editing and modifying) very large patchers, I've become wearisomely accustomed to the fact that Max will start to slow down and eventually crash after editing for a while. I try to remember to quit and restart Max before running a patch after a lot of editing, though it sometimes crashes at some point in the save process. (and the crashed thread is frequently in the CRBrowser , whatever that is). I noticed that (Max) cpu usage in a patch that usually runs around 55-60% was hitting 100% and audio was distorting after editing for an hour or so. (So that's in answer to Roman's question about what happens if one ignores the indicated cpu increase). I quit Max and reloaded the patch and it was back at 55%. So there's _something going on when editing. (Activity Monitor cpu often goes above 100%, but I was told by an Apple person that that is to do with multiple cores and is not an issue.)

So no useful information I'm afraid, just saying that there seems to be an issue, which is really hard to pin down, and no possible explanations have been offered.

Working on (editing and modifying) very large patchers, I've become wearisomely accustomed to the fact that Max will start to slow down and eventually crash after editing for a while. I try to remember to quit and restart Max before running a patch after a lot of editing, though it sometimes crashes at some point in the save process. (and the crashed thread is frequently in the CRBrowser , whatever that is).  I noticed that (Max) cpu usage in a patch that usually runs around 55-60% was hitting 100% and audio was distorting after editing for an hour or so. (So that's in answer to Roman's question about what happens if one ignores the indicated cpu increase). I quit Max and reloaded the patch and it was back at 55%. So there's _something going on when editing. (Activity Monitor cpu often goes above 100%, but I was told by an Apple person that that is to do with multiple cores and is not an issue.)
So no useful information I'm afraid, just saying that there seems to be an issue, which is really hard to pin down, and no possible explanations have been offered.


questions regarding CPU requirements of audio vs. events vs. GUI