Forums > MaxMSP

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


ygreq
July 9, 2011 | 6:19 pm

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


Chris Muir
July 9, 2011 | 7:08 pm

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. –

MIB
July 9, 2011 | 7:10 pm

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 ;)


ygreq
July 9, 2011 | 7:15 pm

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!!


ygreq
July 9, 2011 | 7:16 pm

Thank you both!!!


tom@swirly.com
July 9, 2011 | 7:59 pm

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…


ygreq
July 9, 2011 | 8:48 pm

Thank you for the explanation, Tom!

Wonderful to know this besides the actual tests!


bkshepard
July 9, 2011 | 9:30 pm

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?


MIB
July 9, 2011 | 10:08 pm

@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…


Chris Muir
July 9, 2011 | 10:48 pm

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)


bkshepard
July 9, 2011 | 11:35 pm

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.


Jadie Rage
December 10, 2011 | 6:20 am

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

– Pasted Max Patch, click to expand. –

tyler mazaika
March 30, 2014 | 12:50 pm

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. –

Roman Thilenius
March 31, 2014 | 5:20 am

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.


vichug
March 31, 2014 | 5:38 am

:s

Attachments:
  1. max5vsmax6

Roman Thilenius
March 31, 2014 | 10:17 am

lol.

this is why i use max 4.

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


vichug
March 31, 2014 | 12:32 pm

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

Viewing 17 posts - 1 through 17 (of 17 total)