Manolo Müller

In the last few weeks I have experienced a lot of high CPU load even while building relatively simple MSP patches. I am running Max 8.1.3 on a mid-2015 MacBook running OS 10.13.5, and what strikes me as odd is that on my colleagues MacBook (mid-2013, similar specs) my patches run without breaking a sweat, while on my machine, the fan is turned on and wheezing heavily every time I start DSP. And every time without fail, when I go look in the Activity Monitor, the WindowServer process is right up there, using the same or more CPU than Max itself.

I understand that this process is responsible for updating and drawing to the screen, and if I hide the offending MSP patches in the dock, the CPU load caused by WindowServer dwindles from around 40% to 3%. I also know, that since this is a Mac OS process, the problem might not be caused at all by Max.

Has someone else had this happen to them? And if so, is there any fix, either in Max or at the OS level (updating, factory reset, etc)?

Dear All
In the last few weeks I have experienced a lot of high CPU load even while building relatively simple MSP patches. I am running Max 8.1.3 on a mid-2015 MacBook running OS 10.13.5, and what strikes me as odd is that on my colleagues MacBook (mid-2013, similar specs) my patches run without breaking a sweat, while on my machine, the fan is turned on and wheezing heavily every time I start DSP. And every time without fail, when I go look in the Activity Monitor, the WindowServer process is right up there, using the same or more CPU than Max itself.
I understand that this process is responsible for updating and drawing to the screen, and if I hide the offending MSP patches in the dock, the CPU load caused by WindowServer dwindles from around 40% to 3%. I also know, that since this is a Mac OS process, the problem might not be caused at all by Max.

Dear All
In the last few weeks I have experienced a lot of high CPU load even while building relatively simple MSP patches. I am running Max

strange-performance-issues-high-cpu-connected-to-windowserver-process

Hi, I experience the same issue. Did you figure out anything Manolo?

Starting DSP will immediately cause the windowServer process to spike to ~38%, while it's about ~7% as soon as I turn it off. The patch UI only has 1 interactive UI element - a button object. All processing happens in a single gen object - so no heavy UI work whatsoever.

'Audio status' has CPU at 1%, so no heavy patch.

This behavior is consistent across my patches, just sharing the specific numbers for this one. 

I started noticing this since about 12 months ago, might have been around for longer.

Hi,  I experience the same issue. Did you figure out anything Manolo?

 Starting DSP will immediately cause the windowServer process to spike to ~38%, while it's about ~7% as soon as I turn it off.  The patch UI only has 1 interactive UI element - a button object. All processing happens in a single gen object - so no heavy UI work whatsoever. 

'Audio status' has CPU at 1%, so no heavy patch. 

This behavior is consistent across my patches, just sharing the specific numbers for this one. 
I started noticing this since about 12 months ago, might have been around for longer. 

Unfortunately, I never figured out the reason for the spiking. My upgrading to Mojave interestingly enough mitigated the problem to some extent. But nevertheless it would be interesting to find out if it's a Max, a macOS or even a hardware issue.

- that if i put Max in overdrive mode vs opening max when it's already set to overdrive mode, will put the Max application at 100% when audio is enabled (Max' internal 'audio status' still shows 1% CPU). 

- Restarting max in overdrive mode will fix this. Turning overdrive off and then on again will put it in 'bad state' again, meaning CPU for 'max' process spikes to 100% each time audio is started. This state will persist until Audio is turned off, and Max is restarted. Max will be at around ~10%.

- WindowServer CPU spikes to > 34%, regardless of overdrive or not.

So looks like Max somehow can get in a 'bad state'. I'll investigate if it's scheduler / threading related.

- that if i put Max in overdrive mode vs opening max  when it's already set to overdrive mode, will put the Max application at 100% when audio is enabled (Max' internal 'audio status' still shows 1% CPU).  

- Restarting max in overdrive mode will fix this. Turning overdrive off and then  on again will put it in 'bad state' again, meaning CPU for 'max' process spikes to 100% each time audio is started. This state will persist until Audio is turned off, and Max is restarted. Max will be at around ~10%. 

- WindowServer CPU spikes to > 34%, regardless of overdrive or not. 

So looks like Max somehow can get in a 'bad state'.  I'll investigate if it's scheduler / threading related. 

Found this under 'advanced scheduler settings' https://docs.cycling74.com/max8/vignettes/advanced_scheduler

When checking "open in low resolution", WindowServer CPU drops to about 13-15% (approx 5% when audio turned off). So definitely has an effect.

I'll toy a bit more around with the scheduler settings to see if the overdrive issue could be cured by changing some of those.

On a Retina Macbook, if you have a patch that is performing a lot of user interface drawing, such as rapid updates to JSUI, you are possibly backlogging the queue, which can have an effect on scheduler performance. On these machines, GUI rendering costs are roughly 4x expensive, unless you disable high resolution support (patchers will look worse). To turn off high resolution support for Max, go to the Finder, and Get-Info (cmd+i) on the Max application icon and check the "Open in Low Resolution" box."

When checking "open in low resolution", WindowServer CPU drops to about 13-15% (approx 5% when audio turned off). So definitely has an effect. 

I'll toy a bit more around with the scheduler settings to see if the overdrive issue could be cured by changing some of those. 

Cool, thank you for your research! It's really cutting down a lot of CPU-% (from 50% with hi-res to about 15% for me). This will definitely help for live performance with my patchers (which was the original issue to begin with..).

Just to conclude on this thread, i've spent some time experimenting with the various advanced scheduler settings.

It seems to make virtually no difference on the WindowServer CPU usage.

So my conclusion is that 'low resolution mode' really is the only effective remedy here. 

I wonder if other people are affected by this, nowadays every mac is a retina.

Just to conclude on this thread, i've spent some time experimenting with the various advanced scheduler settings. 

It seems to make virtually no difference on the WindowServer CPU usage. 

So my conclusion is that 'low resolution mode' really is the only effective remedy here. 

I wonder if other people are affected by this, nowadays every mac is a retina.

I allways delete this line in standalone plist file

Screen Shot 2021-01-19 at 10.48.44.png

I allways delete this line in standalone plist file


Thanks for the useful information. I am experiencing the same problems on my retina 2013 MacBook15” with Mojave. this is one of the reasons why I exported all my bpatchers to M4L to run them in Ableton which does far better usage of the multicore processor and GUI.

Thanks for the useful information. I am experiencing the same problems on my retina 2013 MacBook15” with Mojave.  this is one of the reasons why I exported all my bpatchers to M4L to run them in Ableton which does far better usage of the multicore processor and GUI. 

Strange performance issues (high CPU) connected to WindowServer process