CPU, DSP Status vs Activity Monitor

Feb 4, 2011 at 4:29pm

CPU, DSP Status vs Activity Monitor

Firstly, Shark has been really useful for tracking down what objects are using CPU. My problem now is figuring out why there is such a difference in CPU when comparing the DSP Status window to Activity Monitor.

Here are the idle readings (polys~ muted etc)

DSP Status – 5-6%

Activity Monitor – 35%

#54793
Feb 4, 2011 at 5:03pm
#197279
Feb 4, 2011 at 5:08pm

Ah OK, so now it’s how to reduce the non DSP processing!

There are a few threads on that I think (getting rid of number boxes/ unnecessary objects) Are there any objects I should specifically look out for?

#197280
Feb 4, 2011 at 5:20pm

Hello Mike S,

IMHO :

1/ should look for unuseful GUI drawing process (LCD / OpenGL / Scope~) ;
2/ encapsulate to reorganize your patch.

#197281
Feb 4, 2011 at 6:04pm

Thanks Vanille,

Is it safe to assume that the CPU with the audio turned off are the non audio processes?

#197282
Feb 4, 2011 at 6:19pm

Hello Mike S,

I would say yes (not 100 % guaranteed).

Keep the part that you want to test, delete the rest (or do the contrary to search the CPU eater) : you will be sure ;-)

#197283
Feb 4, 2011 at 7:06pm

Attached is the readout from Shark with the audio off when the patch is first loaded.

Max/MSP on its own with audio off in Activity Monitor takes about 6% CPU,

The CPU in Activity Monitor with the patch loaded and audio off is roughly 26%

The readout from Shark shows Max at roughly 12% with audio off, leaving 8% somewhere else?!

Is the CPU reduction more of a question of trial and error, or can anyone make sense of the Shark data? Or perhaps both?

Thanks again

[attachment=153133,1769]

Attachments:
  1. cputest.jpg
#197284
Feb 5, 2011 at 7:35am

Hello,

I use Shark to find bottleneck in my code when i’m doing an external but never when i’m patching : it is not very easy to interpret the result as most of time CPU cost is sprayed between tons of Max’s library functions or Juce stuff that i don’t really understand ; except if you are a maxMSP expert developper it may be your case too. So for me it is mainly trial and error ; encapsulation ; then delete blocks one after the other.

Anybody else opinion ?

#197285
Feb 5, 2011 at 11:43pm

Shark might be useful to find the objects which really takes continuous usage of CPU, such as DSP objects.

#197286
Feb 6, 2011 at 1:48pm

Hi Emmanuel,

Yes, I’ve used Shark to tweak the DSP objects, it is indeed great for that. My problem now is making sense of that data, or more likely finding the objects that are causing this idle CPU %

@ Vanille, I think trial and error is indeed the way forward, thanks again

#197287
Feb 6, 2011 at 2:24pm

You can’t go further than what you did. Basically now you see that you have a bunch of things that are redrawing, and that’s taking more CPU than the actual calculation of the patcher. I wouldn’t worry too much about the idle processing, although this has been widely improved in Max 5 compared to Max 4, Max will always take some CPU while doing “nothing”, the scheduler has to be maintained ready, among other things.

#197288
Feb 6, 2011 at 3:01pm

I can always use fewer objects (I have already got rid of quite a few, and can get rid of more) What is redrawing? Is it related to graphics?

RE the idle processing, I’m not concerned about Max itself, obviously I can’t do anything about that. But I presume that less objects = less CPU, so at least I can try and optimise the ‘Max’ side of the patch?

#197289
Feb 6, 2011 at 4:57pm

Hello Mike S,

3 possibilities :

- you have few objects/subpatch very expensive : find them ;
typically Graphic User Interface ;
- you have thousand instance of same subpatch/object ; time for poly~ ? ;
- don’t lose your time to gain 1 % !

Less objects = Less CPU ; FALSE ; for instance few [prepend] [trigger] [append] are often better than one [sprintf] ; in term of CPU ; but in term of readability ? … but almost sure than gain is not significant …

just my 2 cent ;-)

#197290
Feb 6, 2011 at 6:18pm

- don’t lose your time to gain 1 % !

@vanille, That’s the key point! Don’t optimize unless you need to. (I’m less optimistic on the sprintf comment though ;-)

#197291
Feb 6, 2011 at 6:43pm

Thanks again guys. The reason I’m conscious of CPU is that I am going to sell the application commercially.

#197292
Feb 6, 2011 at 6:58pm

Hello,

@Emmanuel Jourdan :

– Pasted Max Patch, click to expand. –

according to this stupid benchmark ;-)

#197293
Feb 6, 2011 at 10:01pm

oh yeah sorry I misread your post. sprintf is definitely slower, and that’s not his job anyhow ;-)

#197294

You must be logged in to reply to this topic.