[PD] CPU cost: throw~,catch~,send, subpatches, etc...

IOhannes m zmoelnig zmoelnig at iem.at
Wed Nov 8 20:20:50 CET 2006


glerm soares wrote:
> Hello,
> 
> I just wonder:
> using throw~, send, receive, catch~ objets like it's more CPU expensive
> than
> just plug with "cables"?

[throw~]/[catch~] is more expensive than [send~]/[receive~] (due to the
adding involved; last time we did tests (few years ago), the difference
was _rather_ big (we were using lots of [throw~]/[catch~]), but i don't
recall any numbers; i think things have become better (though i don't
know why...)
just "cables" share functionality of both [s~]/[r~] and [t~]/[c~] so i
guess there performance should be inbetween ;-) (or worse than both);
but i have never tried, and i doubt that these performance issues need
to be considered on recent hardware unless you are have illions of
connections (read: not in patches that i come usually across); in this
case you should probably re-think the way you build your patches ;-)

of course there are other performance critical applications, where you
just need 1% of less CPU load for things to run stable.

> 
> and what about subpatches? is much more CPU expensive than just let all
> conections in the same patch?

last time i tried (1999) there was no difference; my non-subpatched
patch was really huge (the first one (and probably the last one) i made
that took several screens to display...) and i have not been able to
measure any difference; the patch ran fine for 2 weeks with a load of
95% (i could even do some minor patching while it was running) in a
rather big installation.

and finally: it is rather simple to do such benchmarks yourself: just
create an abstraction that does what you want to measure and then create
a "large" number of instances ("large" depending on the amount of CPU
the patch needs; you should get at least a two-digit load (30%-60%))
then create an abstraction with the alternative and create the same
number of instances of abstractions. compare the 2 loads.

mfg.adsr
IOhannes

PS: i guess there are almost no people subscribed to pd-dev that are not
subscribed to pd-list; so you don't need to post to both lists




More information about the Pd-list mailing list