On Wed, Aug 7, 2013 at 2:57 AM, Roman Haefeli <reduzent@gmail.com> wrote:
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
> On 08/07/13 03:15, Miller Puckette wrote:
> > Hmmm...  I was umnder the impression that, except for the overhead of block~
> > and switch~ objects, there would be no difference in DSP execution time
> > between a patch having lots of subpatches and one with the same amount of
> > computation all thrown in one window.  I haven't made any measurements but
> > theoreticall at least there shouldn't be any difference.
>
> i once did make measurements, and they showed that your assumption is
> correct.
>
> or at least, it showed that it *was* correct at that time. this was on a
> P2-400MHz in 1998 or so, where a 16 channel spatialization patch would
> eat about 95% of the CPU - regardless of whether you used a single huge
> patch or organized the code into subpatches/abstractions.
>
> eventually i went for using abstractions, and let the PC run at 95% for
> the 2 weeks show.

I once made some informal tests to measure the overhead of [switch~]. It
turned out it is quite big and if you're running hundreds or thousands
instances of [switch~] you probably gain nothing by turning DSP off in
subpatches. I don't know what the sweet spot is it seems using [switch~]
is only worth for subpatches with a minimum amount of (DSP) complexity.

Roman

I don't know why this is so...  
When you add a [switch~] object, it adds a prologue and epilogue around the perform routines from each object in the subpatch.  The runtime behavior is just like [block~], except when the patch is switched off, the switch prologue returns a pointer to the epilogue, instead of the next item in the dsp chain (don't quote me--I may need to read some code to find exact behavior, but that's the gist of it).

To me, this is pretty minimal and reasonable.  Maybe there's an unintended consequence like cache misses when skipping over part of the dsp chain.

 Chuck