Hi !

I think the question is pretty clear. I have a patch that is hard to read because cables are crossing all over. So I was thinking of replacing some with send/receive objects. But then I thought "hmmm, ... is it going to make things slower !?". And here I am asking you

Sébastien

I believe the order of execution is safeguarded also when using send/receives (not the audio one's which introduce a delay equal to the dsp blocksize). So you won't notice any delays.

Thanks domien, but I mean : is slower performance-wise ? I am wondering is it an extra-gimmick that takes more memory, and therefore is not so good if you want high performance, or is it exactly like a cable and doesn't consume more ?

I think i've read on the list that it's exactly the same thing performance-wise.

I remembered having read the same thing, ... but somehow it seems hard to believe

Why ? I guess that if you look in the code it's basically like an invisible cable.

Except for one thing ... if you create send with no argument, you can route dynamically.

So if send with no argument and send with an argument use the same native object, then it's got to be more complicated than a normal cable. No ?

I don't really know, but if you want to hunt the last bits of available cpu time in sends and receives, you've got to have an impressive patch-fu
Jokes aside, you should try to generate two enormous patches (one with cables, and its twin with send/receives) and compare cpu and memory prints.

Hahaha ! Noooo. My patch is ridiculously small. I was just curious that's all

> you should try to generate two enormous patches

That's a good idea, and I will do it - when I find time

I don't think it should really be any different performance-wise. On the C side of things, a connection is just one object writing to memory (outlet) and another reading from it (inlet). [send] and [receive] internally do the same thing. The only difference I can think of is that you still have to connect to the [send] and from the [receive].

This:

[bng]
|
[send test]

[receive test]
|
[bng]

instead of this:

[bng]
|
[bng]

Because of that, there's basically one extra read/write in the chain. But accessing memory is pretty much the fastest thing a computer can do, so it's likely unnoticeable.

I get out that the calbe is ~ 2.25 times faster than the s-/r-stuff... I guess due to what Maelstorm mentioned above.

Personally I prefere using cables. Not only because of the CPU-issue but also to keep things "local". In contrast, using s/r's all the time would distort the graphical-programming concepts (+ overview & order of execution).
Using them for dynamic routing is the most common use over here...although I wonder why the [receive] dosn't have a selection-inlet.
I thought it just wasn't possible pd-wise, but then i discovered the [receive13]-object, which does exactly that (and more???) via a [set xyz(!

Actually, I like send/receive very much, I have some patches right now that look very ugly and they would definitely need that.

I guess patch design is the more deciding factor on using s/r or cables. Sometimes it's just impossible - in how i'm patcing of course - not to use s/r. I have a masterpatch which communicates to others, so using cables are not an option. With patches themselves i always name all gui widgets and r them inside a patch. The inner workings of the patch however are usually fully cabled. As long as you create enough logical subpatches you can often keep things a bit tidy, which improves (future) readability. When using plentys of r/s it's hard to keep track of the order of execution which can lead to nasty bugs sometimes.