just make a test ;-) put a lot of each one and look at activity monitor / DSP Status. I highly doubt that there's going to be much of a difference in DSP Status, when the number~ are hidden this should be more or less the same than snapshot~, but when they are visible it will probably cost something to draw... Just guessing here.

Also, intuitively I can't imagine that snapshot~ is inherently "CPU intensive". It doesn't perform ANY math at all worth mentioning. All it does is grab the first value in a signal vector (or whatever location offset in the vector you specify) and output it, then schedule a future such event if its clock time is nonzero. Of course, if you have its clock time set to 1, that makes it moderately "scheduler intensive". As Emmanuel suggested, just test and compare the two objects if you're concerned.

dont forget that the CPU required to display the graphics will not be shown by dspstate.

snapshot takes the more CPU the more instaces you use, for the sheduler thing ej is talking about. not good when you also want to sequence a lot of data.

but it is not only the sheduler - you can often save some CPU by running meter~, average~, avg~ or snapshot~downsampled.

-110

On a related note, is there a way of getting a more precise estimate of the processor load of a patch so I can compare multiple ways of achieving the same goal? The dspstate-thingy doesn't really do the trick for me.