I was surprised to find that a portion of a patch that is drawing to two 3-slider multislider objects in line scroll mode, updated at 10ms / sample, was using nearly 30% of my CPU.

This is on a Macbook pro 2x2GHz, Mac OS X 10.4.11, Max 5.0.4. Overdrive is off, although this does not seem to affect the situation.

When I sample Max in the activity monitor (activity monitor -> get info -> sample), it looks like most CPU time is spent by the JUCE component that is drawing these sliders.

Here's a more reproducible example. Perhaps others can tell me if they're seeing similar behavior:

-> Open the multislider help file and turn on the EKG example (which runs at 40 ms sample period).

I find about 9% increase in CPU usage before and after doing this. Under Max 4.6, the increase was 1-2%.

With the (small) righthand multislider enlarged (doubling both dimensions) I see 15% more CPU usage relative to when the patch is closed. That's a lot of cycles (~10^7) to spend refreshing a rectangle of ~10^4 pixels! Under Max 4.6, I see something like 3-4% CPU usage under these circumstances.

Are others seeing similar behavior, or are my Max 5 settings gone amuck?

This is on a Macbook pro 2x2GHz, Mac OS X 10.4.11, Max 5.0.4.  Overdrive is off, although this does not seem to affect the situation.

Here's a more reproducible example.  Perhaps others can tell me if they're seeing similar behavior:

-> Open the multislider help file and turn on the EKG example (which runs at 40 ms sample period).  

I find about 9% increase in CPU usage before and after doing this.  Under Max 4.6, the increase was 1-2%.

With the (small) righthand multislider enlarged (doubling both dimensions) I see 15% more CPU usage relative to when the patch is closed.  That's a lot of cycles (~10^7) to spend refreshing a rectangle of ~10^4 pixels!  Under Max 4.6, I see something like 3-4% CPU usage under these circumstances.

max-5-multislider-cpu-mystery

Quote: Yon wrote on Thu, 11 September 2008 04:40

----------------------------------------------------

> Are others seeing similar behavior, or are my Max 5 settings gone amuck?

I'm getting similar results. Enabling the "EKG" in the multislider help file results in a 6-7% cpu increase for 5.0.4 vs 2% in 4.6.3.

Moving the slider in the "Scrolling display example" above the EKG also results in spikes of up to 7% in 5 vs 2-3% in 4.

Sampling show a lot of JUCE, yes, but that's what you'd expect, right? Juce is what draws to the screen from what I understood.

I don't like the CPU increase/peaks though. Waveform~ was also very inefficient just after 5 was released, but I haven't checked it in 5.0.4 yet.

Quote: Yon wrote on Thu, 11 September 2008 04:40
----------------------------------------------------
>
> Are others seeing similar behavior, or are my Max 5 settings gone amuck?

I'm getting similar results. Enabling the "EKG" in the multislider help file results in a 6-7% cpu increase for 5.0.4 vs 2% in 4.6.3.
Moving the slider in the "Scrolling display example" above the EKG also results in spikes of up to 7% in 5 vs 2-3% in 4.

I don't like the CPU increase/peaks though. Waveform~ was also very inefficient just after 5 was released, but I haven't checked it in 5.0.4 yet.


> I was surprised to find that a portion of a patch that is drawing to two 3-slider multislider objects in line scroll mode, updated at 10ms / sample, was using nearly 30% of my CPU.

I recently bought Max 5 although I'm still working in 4.6.3 for now. I bought it because I know that eventually I will make the switch anyway, so I might as well have a copy now so I can already play around with it a little every now and then, open max5 examples from the forums etc etc.

Which brings me to this multislider issue. I use multisliders quite often for display purposes. I just made another simple patch emulating the way I might use a few multisliders for display duties. The thing takes my cpu from 5 to 17%. This is on a 2.16GHz MBP. In any somewhat serious performance patch this is unacceptable. I can not sacrifice 10% cpu for a scrolling display of 3 streams of numbers. (and why is max using 5 % cpu when it is doing *nothing* anyway?)

Of course I could live without this type of display - it is just that in Max4 it was cheap enough to be justifiable. Not in 5 though. Too expensive. I find this a bit strange.. 2008, a pretty serious laptop computer... I'd expect that displaying a few streams of numbers should be possible at a reasonable cpu "price", right?

Should we consider using multisliders for display purposes bad practice now? Will this issue at some point be addressed, because it *could* be optimized, but just wasn't any priority so far? Or is this just the nature of the JUCE beast?

If this is indeed the nature of the beast, it will probably be an issue with objects like meter~, waveform~ and others too and in that case Max5 might force us to make serious changes in the way we program our interfaces..? Watch out for anything that needs regular graphic updates???

Thanks in advance for any thoughts, comments or suggestions.

PS: I love the highly improved readability from the native font rendering. Thanks for that!

Quote: Yon wrote on Thu, 11 September 2008 04:40
----------------------------------------------------

Which brings me to this multislider issue. I use multisliders quite often for display purposes. I just made another simple patch emulating the way I might use a few multisliders for display duties. The thing takes my cpu from 5 to 17%. This is on a 2.16GHz MBP. In any somewhat serious performance patch this is unacceptable. I can not sacrifice 10% cpu for a scrolling display of 3 streams of numbers. (and why is max using 5 % cpu when it is doing *nothing* anyway?)
Of course I could live without this type of display - it is just that in Max4 it was cheap enough to be justifiable. Not in 5 though. Too expensive. I find this a bit strange.. 2008, a pretty serious laptop computer... I'd expect that displaying a few streams of numbers should be possible at a reasonable cpu "price", right?

Thanks in advance for any thoughts, comments or suggestions.
Klaas-Jan Govaart

I had spoken to a friend prior to this. at that time he expressed his dismay at max 5 performance, as measured using a data generation patch he uses to benchmark across computers. i now suspect that the performance hit he was seeing was mainly due to multisliders used for display in his patch.

i've simply added gates to all instances of multislider, and turn them on only as needed. i also found that some of the max 5 scheduler options improve the situation somewhat. i'd be similarly careful with other dynamic UI elements.

i guess one would see much better performance with an opengl based scrolling data display, if someone has time to cook up such a thing.

I had spoken to a friend prior to this.  at that time he expressed his dismay at max 5 performance, as measured using a data generation patch he uses to benchmark across computers.  i now suspect that the performance hit he was seeing was mainly due to multisliders used for display in his patch.

i've simply added gates to all instances of multislider, and turn them on only as needed.  i also found that some of the max 5 scheduler options improve the situation somewhat.  i'd be similarly careful with other dynamic UI elements.

Quote: Yon wrote on Fri, 12 September 2008 22:02

> i guess one would see much better performance with an opengl based scrolling data display, if someone has time to cook up such a thing.

That's a nice idea... Thx! I might cook that up myself some time next month on a rainy afternoon.

Well, for now, I'll just stick to 4. I like how it looks, and performs. But I hope that eventually this situation will improve.

Quote: Yon wrote on Fri, 12 September 2008 22:02
----------------------------------------------------

Well, for now, I'll just stick to 4. I like how it looks, and performs. But I hope that eventually this situation will improve.


Max 5 - Multislider - CPU Mystery