route performances

Sep 30, 2012 at 8:30pm

route performances

Hi there, I have a couple of questions, related to best practice with [route] object.

if I have a route object like that:
[route case1 case2 case3]
and case3 occurs very very often compared to case1 (I mean almost real time update), is it good to use a global route including it or should I route it from another way (= separate into 2 route for instance) ?

Is there a particular order to place our “cases” ?
for instance, if case 3 is occurs more often than case1, should we place it before like that :
[route case3 case1 case2 ] ?

best
j

#64557
Sep 30, 2012 at 9:02pm

a seperate object would not save anything, but eat up more cycles when the lesser cases occur.

i *think* the check is begun from the _rightmost object, so it can be a good idea to put
case3 on the _last position. someone pls correct me if i am wrong.

#232931
Sep 30, 2012 at 9:06pm

thanks Roman.
it can look like to be a strange question, but indeed, this is one of the most used object and it could be nice to have this referenced here :)

#232932
Sep 30, 2012 at 9:28pm

it is not strange at all, i totally understand your thought behind it.

i create realtime apps with max in order to run them on 10 years old computers and so i think that “optimisation” can not only be a lot of fun, but also allows you to do two times more things at a time than without.. :)

sometimes i think the inner structure of objects should be part of their documentation.

-110

#232933
Sep 30, 2012 at 9:29pm

“sometimes i think the inner structure of objects should be part of their documentation.”

AGREE 100%
let’s wait for some c74 guru to answer here :p

#232934
Oct 1, 2012 at 1:29pm

I won’t argue that 10 years ago this could have been a performance issue, but nowadays you would have to make a lot of iterations to even notice the difference. Nevertheless, in the case of route, the order doesn’t matter at all, because it search for multiple matches anyway so it doesn’t stop when it find the first match, all the items needs to be compared.

– Pasted Max Patch, click to expand. –
#232935
Oct 1, 2012 at 1:37pm

thanks a lot Emmanuel.

btw, I saw a couple of time Max 6.0.8 written when someone posts a patch.
is it related to the last build of Max 6.0.7 of the previous week ?

#232936
Oct 1, 2012 at 1:49pm

probably means some people are running the beta of 6.0.8…

#232937
Oct 1, 2012 at 1:51pm

(dtr: probably :p)

#232938
Oct 1, 2012 at 3:02pm

something like that…

#232939
Oct 2, 2012 at 12:36am

i bet ej has 609 already.

but thanks for clearing up the mystery about order.
when i think about it is clear why: of course it has to be checked against all arguments, as two of them could be the same symbol. :)

-110

#232940
Oct 2, 2012 at 3:40am

I am quite dismayed to learn of this behavior. I always assumed that [route] was implemented using a jump table or an associative array for O(1) performance. I’m even more bothered that even after a match, it keeps checking the rest of the values. I don’t see how there’s any benefit to this implementation.

I just went back and read the description of route and even then I would have assumed that it would stop once it found a match.

Someone needs to implement [routeEx] with O(1) behavior.

#232941
Oct 2, 2012 at 4:14am

may be [dict.route targetType: something] is big O

#232942
Oct 2, 2012 at 9:54am

@dhjdhjdhj : because if you have, say, a [route 8 int], and you input an 8, you want it to output through both outlets, and all other integers out only the int-related outlet.

edit : ah, exactly what Emmanuel Jourdan said, my bad.

#232943
Oct 2, 2012 at 12:28pm

I’ve never really considered mixing values and types like that in my programming style. Intuitively I think it would be hard to understand what’s going on, in terms of quickly understanding the algorithm. Can you give me an example where this is actually useful? And if there is a use for it, wouldn’t it be cleaner (and perhaps even more importantly, clearer) to use the following instead?

– Pasted Max Patch, click to expand. –
#232944
Oct 2, 2012 at 11:34pm

one example where it is useful is when you use [append] and [route] to send lists into subpatchers such as custom abstractions or [poly~].

you might want to send a notenumber with or without a velocity value, and some parameter which exspects also ints which are tagged with “filter” into a patcher. and so you need [route int list filter] to get the incoming data where it belongs.*

i use [route int float list bang] on a daily basis, at least more often than [route 10 20 30 40 50]. for the latter there would be alternatives – for a typecheck or for symbols not.

p.s. *) this example is wrong. do you see it?

#232945
Oct 2, 2012 at 11:52pm

I still don’t understand — in your example, an incoming item will still only match ONE of the arguments so after you get a match, there would be no need to keep testing after you find a match.

#232946
Oct 3, 2012 at 1:05pm

@dhjdhjdhj : indeed, your patch is possible, but really counter intuitive and less readable and maybe more expensive (not sure of this too, but the difference is little anyway) imho. Let’s just agree to disagree :) and i think it’s nice to have the choice.

As for an example where it’s actually useful… weeell, let me think…. i’m nearly sure i used route that way at least once, can’t say when to be honest. But it could be useful, doubtlessly, int eh case of passing something inside a subpatcher… maybe.

#232947
Oct 3, 2012 at 2:50pm

Well, in fact I question your claim that it’s counter-intuitive. For a start, that example was just a way to demonstrate how routing could be done that would support the case where an argument is repeated.

I think the idea of allowing repeated arguments is itself counter-intuitive and nobody has demonstrated a real-world example to justify supporting repeated arguments. I would also bet that if there are examples, they will (a) be rare and (b) turn out to be more convoluted than necessary. In other words, in the rare case that the functionality is needed, the example I used to handle it will be cleaner.

If you therefore disallow repeated arguments, one could implement [route] significantly faster when there are many arguments, important particularly when data is arriving at a high rate.

Note that my comments are based on my experience as a programming language designer, not as an artist.

#232948
Oct 3, 2012 at 3:09pm

Hello,

@dhjdhjdhj : “Someone needs to implement [routeEx] with O(1) behavior.” Is it a paid job ;-)

#232949
Oct 3, 2012 at 3:36pm

i honestly don’t have a programmer experience, and don’t really realize what a difference it makes cpu wise, but what is counter-intuitive for you is not the same as for me :)

#232950
Oct 3, 2012 at 3:39pm

I have a few cases where I actually have about 24 (all integer) arguments in a router — as time permits, I’m going to go back and take a look at their performance and I’ll probably end up hacking up my own version for handling this kind of thing more efficiently. Clearly it has not been an issue for existing use cases or it probably would have been addressed by now. There may even be a third party object already that someone’s done.

#232951
Oct 3, 2012 at 3:40pm

Of course — but that’s one of the benefits of these interactions.

—————
but what is counter-intuitive for you is not the same as for me :)

#232952

You must be logged in to reply to this topic.