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 _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list