there ate like hundred different was to doings with many object
And what object do I need to avoid when making a large patch?

Thank you I wish there was a CPU chart of all the object but Mmm
So why do people use lots or s objects and r objects
Is it wong to use cables everywhere?

i want complete a question:
how to compare the two patches?
how to measure CPU time used by each?

i got my info from a C programmer who ran some external diagnostic tool. not too sure about all that. Also, the info i had is on my old computer which is unfortunately buggered.

i've found [cputime] object and try to compare [/ 2],

• and [>> 1]
  to complicate i made ​​them 10 times
  in any case the output is 0

@mozz said:

i've found [cputime] object and try to compare [/ 2],

• and [>> 1]
  to complicate i made ​​them 10 times
  in any case the output is 0
  Ten of them is not much. Why don't you try thousands ?

And of course [/~ 2] and [*~ *0.5] do 'cost' much more than [/ 2] and

• ... so you won't need thousands of 'audio objects' to get a measure.

to test [/ 2] i send float to the chain and get a bang from the end
to [cputime] right inlet
i can't imagine how to test [/~ 2]

Usually I use the little 'load meter' patch provided in Pd's menu, while the patch to be tested is running.

@mod said:

* [tabread4~] is pretty hungry because of its 4-point interpolation. I found that making a simple 2 point interpolation for sample playback worked ok. (use 2 [tabread~] objects, and a [+~ 1] before the 2nd one, and then send the output of both [tabread~] objects into the left side of [*~ 0.5] to average them.

It would actually be better to use a weighted average. Take the fractional part of the table-lookup signal and use that to determine the weights.

y = (1-a)*array[int(n)] + a*array[int(n+1)]

where a is the fractional part of n, and n is the table-lookup signal. If you just do a simple average of them (a=.5), you get a lowpass filter. Actually, linear interpolation always has a lowpass effect, but it's most pronounced at a=.5, and the filter opens up toward a=0 and a=1. I attached a patch to illustrate.

Just some other things I'd recommend:

* If you don't need to see a sample, put it in a table. Pd's array drawing is pretty bad, especially in "draw as points" mode, because it does a redraw of every sample even if only one has been changed.

* If you want to see a sample but don't mind it looking imperfect, use "draw as polygon" mode for the array. It's much faster.

* Along the same lines as mod's [noise~] example, don't calculate the same thing in more than one place in the patch. Do it once and send it to a [send] or [value] object so you can grab it anywhere in the patch.

* If you can take a calculation in your patch and write it down as an equation, it might not be a bad idea to do so. You may find that you can simplify it with some very simple algebra. It's not always so clear how to simplify things in patch-form.

* Also, and I can't stress this enough, keep your patches looking clean. This doesn't make it more efficient itself, but it will make it a lot easier to see where it can be improved.

http://www.pdpatchrepo.info/hurleur/lin-interp.mmb.pd

and of course you should always switch the dsp off for subpatches and abstractions that arent needed. clever encapsualtion and switching logic is the most important part from my experience.

also make sure metros are off when not needed and try to spread out metro bangs from as few metro objects as possible.

one thing i encountered is that it is important to cut the control connection to line~/vline~ objects when the dsp in their subpatch is turned off. for some reason they seem to keep accumulating incoming messages and that drives the cpu crazy.