Which method is faster? Patch cords or send/receive pair?

Jul 9, 2011 at 6:19pm

Which method is faster? Patch cords or send/receive pair?

This is bugging me for years now. I am guessing it is the same thing, but I would like to know an opinion of somebody who is more advised than the rest of us. Maybe somebody working at Cycle74? :D

I found this thread (http://cycling74.com/forums/topic.php?id=24190) but it talks about M4L.

Thank you so much!
ygreq

#57940
Jul 9, 2011 at 7:08pm

It looks like roughly one micro-secend per message. Probably not enough to worry about, except in pathological cases.

– Pasted Max Patch, click to expand. –
#207907
Jul 9, 2011 at 7:10pm

test it for yourself with the patch below. for me it’s about twice as slow… 0.55 for patchcord, 1.1 for s/r pair

– Pasted Max Patch, click to expand. –

Chris beat me to it ;)

#207908
Jul 9, 2011 at 7:15pm

OOh! Nice test!

It’s almost half the time in my case with your test! I guess I am a pathological case! :P

3.846177 vs 6.235269

I am banging/changing 8 [scale] objects at a time besides other stuff so I need faaast!

Thank you so much!!

#207909
Jul 9, 2011 at 7:16pm

Thank you both!!!

#207910
Jul 9, 2011 at 7:59pm

You’d naturally expect patch cables to be cheaper than send/receive pairs! (In fact, I’m a little surprised the difference isn’t more pronounced).

If you wanted to write code to represent “a patch cord” it would simply be “a subroutine call”. In a send/receive it’s “a name look up and then a subroutine call”. More, the name lookup is not obvious because of the different levels and places that a receive could be…

#207911
Jul 9, 2011 at 8:48pm

Thank you for the explanation, Tom!

Wonderful to know this besides the actual tests!

#207912
Jul 9, 2011 at 9:30pm

Thanks for the examples. I have a question MIB. I’m a bit puzzled by the fact that the [t i] objects aren’t hooked up to anything related to the timing. Does merely having them connected to the [uzi] cause [uzi] to run a different speeds?

#207913
Jul 9, 2011 at 10:08pm

@bkshepard I didn’t want a UI object slow down things since, I hope, nobody would connect an uzi to a number object in a real-life situation… I also just realized that I hooked up the wrong outlet of uzi to the [t i]. It should of course be the right outlet. Not entirely sure what you mean by “aren’t hooked up to anything related to the timing”
The timer starts when you hit the bang, uzi does its things as fast as it can, when done the timer is stopped. depending what you hook up to the uzi it will take longer or shorter…

#207914
Jul 9, 2011 at 10:48pm

Uzi does all of its work in one scheduler frame. It just needed to be hooked up to anything, for this example. It should just be the same on both tests (patchcord & send/receive)

#207915
Jul 9, 2011 at 11:35pm

Thanks MIB and Chris both! That answers my question. Sorry for the confusion in my question, I was referring to the fact that the uzi was connected to both the timer as well as to the [t i] object, but the [t i] was not subsequently hooked up to anything else.

#207916
Dec 10, 2011 at 6:20am

For comparison, I added a pvar version which is slightly slower than s/r.

– Pasted Max Patch, click to expand. –
#207917
Mar 30, 2014 at 12:50pm

This threads been idle for a while, but I was surprised by Jadie’s finding about pvar. I think the test in that patch is not ideal because there is an unnecessary intermediate [numbox]. With pvar you can go directly to the final numbox, and when you do that the pvar result is slightly faster than the s/r result.

I got curious and tried a few other options with the following results. Results ordered from fastest to slowest.

cable – 3.1
cable (with intermediate ‘thru’ object) – 3.4
pvar – 4.5
send / receive – 5.0
pattrforward (with no extraneous cables) – 7.9
pattrforward – 8.2
pattr (bound, with no extraneous cables) – 17.5
pattr (bound) – 19.7

…and yet I use bound pattr’s a lot out of convenience because I rarely need data throughput to be so fast.

– Pasted Max Patch, click to expand. –
#285278
Mar 31, 2014 at 5:20am

pvar and s/r have in common that both are attaching a name to the data sent.

whereas pvar creates a namespace, i think s/r is doing something very very similar to what [prepend] and [route] are doing to a message.

#285321
Mar 31, 2014 at 5:38am

:s

Attachments:
  1. max5vsmax6
#285322
Mar 31, 2014 at 10:17am

lol.

this is why i use max 4.

would love to make you jealous with my efficiency, but i dont have [cputimer]. :D

#285352
Mar 31, 2014 at 12:32pm

bah ! just need a [gen] for control-rate data and voilà…

#285367

You must be logged in to reply to this topic.