Hi there! I haven't been puredating for a while. I have BIG problems with dsp load and I don't know how to solve it. I created a big patch to play live. It contains several sub-patches and abstractions. Honestly, I think the code is very untidy and inefficient and I resolved to redesign it.

I'm on OS X , Book pro 2.9 Ghz i7, 8GB Ram. The main problem is that my program seems to overload CPU. Whenever I open it, Activity Monitor shows constantly 99%-100% CPU usage.

1. I would like to know which are the best and more informative ways to monitor CPU usage within a big patch. I would love "local" information.

Laptop fans start like if the system was being raped and it looks as if the laptop is going to take off. The program gets super slow and it takes seconds to answer my movements. Things became pretty unusable. I tried several things: First, [switch] off the program so that I can study my code and see where are my cpu burglar routines. I saw switch just shuts up audio but computation remains. Turning audio off with Cmd+. doesn't help neither.

2. Is there a way to see a complex patch and make sure no computation is taking place? I thought about taking images of every abstraction/subpatch within. Obviously, reading the patch as text file is nightmarish.

Alternatively, I delete modules one by one in order to inspect where I have a considerable decrease of cpu usage. Problem is, deleting abstractions or subpatches causes PD to crash almost every time I do this.

3. Why?

As far as I know, things one should avoid to increase efficiency are:

• Do not overload patch with GUI components. Is this also true for bangs? Sometimes I use gui bangs to convert a message signal into a bang (throw event x when parameter y is changed) Is this problematic? Are signal graphs very cpu demanding? what about knobs, faders, etc?

• Use data signals instead of audio signals when possible. I like to use audio signal to control audio, but I'm aware this should not be escalated quickly.

4. Do you know a comprehensive tutorial on efficient design? Is there any place I can check how come cpu-demanding are every object?

Thank you guys for your time, I'm in desperate need of your help!

I also increased latency up to 500 ms as recommended in this thread:
http://puredata.hurleur.com/sujet-6781-dsp-cpu-usage

@cacosomoza said:

I saw switch just shuts up audio but computation remains.

This sounds like it may be a problem with non-audio computation. Do you have any big [until] loops going on? I've found that [until] loops that take more than a few seconds can really get your laptop fans going.

Alternatively, I delete modules one by one in order to inspect where I have a considerable decrease of cpu usage. Problem is, deleting abstractions or subpatches causes PD to crash almost every time I do this.

Try opening the Pd and the patch from the terminal using the -noloadbang flag. Then, your calculations will be disabled by default and hopefully you will be able to delete parts, save the new patch (with a different name, of course), and try to load it normally. I suspect this is all coming from loadbanged calculations, so that would be a good place to start.

• Do not overload patch with GUI components. Is this also true for bangs? Sometimes I use gui bangs to convert a message signal into a bang (throw event x when parameter y is changed) Is this problematic?

It's completely unnecessary. Just us [t b] to convert to a bang.

Are signal graphs very cpu demanding? what about knobs, faders, etc?

With the gui update in .43, simply having gui objects isn't such a big deal anymore. However, it's still a problem if you're using them in your calculations. For example, if you need to grab a value from a slider, and you're doing it by banging the slider's inlet. You'd be better off having the slider's value stored in a separate [f ] and banging that instead.

Updating the gui components can also be a problem, so make sure you use things like [change] and/or [speedlim] to keep from unnecessary updates.

• Use data signals instead of audio signals when possible. I like to use audio signal to control audio, but I'm aware this should not be escalated quickly.

The main thing with this is to just make sure the message-rate signals aren't too fast. I've found that, because the message system isn't clocked like the dsp graph, it can be inefficient and cause drop-outs if you ask it to do too much. Again, [change] and [speedlim] can be helpful, as well as just making sure they have a relatively slow rate for things that update continuously (i.e. LFOs).

4. Do you know a comprehensive tutorial on efficient design? Is there any place I can check how come cpu-demanding are every object?

The absolute best thing you can do is just what you suggested in the beginning: go back over your patch and redesign it. You may find a lot of redundant calculations. Try and find a way to do the same thing with less objects.