[L2Ork-dev] [t a] speedup

[Albert Graef]

I'm all for optimizations, especially if they come cheap, but are you
sure that it's worth going through all that pain? It would be good to
have some real figures about that trigger bottleneck before embarking
on this. Also, I'd be wary of the potential quadratic blowup of
(hidden) connections, this also comes at a cost which might just
outweigh the gains in many cases.

I'd start out by just adding a new "fan-out" object like "t" which
just distributes its input to its outlets. That should certainly be an
improvement, maybe that's already good enough, and at the very least
you get a better idea about the performance gains that you might hope
for with the full-blown solution.

On Thu, Apr 5, 2018 at 8:36 PM, Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> Hi list,
>
> I was looking at various ways to speed up trigger,
> but none of them compare to this:
>
> 1. make a new class called "trigger_fast" with a constructor
> of 0 (i.e., you can't create it by typing trigger_fast in an object box.
>
> 2. Inside trigger_new, check to see if all the arguments are
> "anything" (or "a").
>
> 3. If all args are anythings, create a trigger_fast object instead of
> a trigger object, and return its reference.
>
> 4. In the connection logic in g_editor.c, check if a new connection is
> coming/going to a trigger_fast_class object.
>
> 5. If so, make the linked list graph bypass [t a] altogether and
> connect into the correct objects above and below the trigger_fast
> object as necessary to get the ordering specified by trigger's
> one-to-many right-to-left semantics.
>
> 6. Draw the connections in the diagram as the user made them.
>
> 7. Have a debug mode or toggle to show the connections as they are in
> the linked list vs as the user made them.
>
> This is probably a pain to implement, but it would have the following benefits:
>
> * encourage users to use [t a] and ignore the complicated trigger args
> which have inconsistent behavior and most of the time just cause
> confusion
> * get a big performance increase on _all_ platforms _regardless_ of
> the c compiler used as users employ [t a] more often
> * be completely backwards compatible with whatever the current
> behavior of trigger is for the other args and arg combinations.
>
> That would cover all use cases except [t b] and mixtures of [t b a].
> But I think it still covers a lot of cases.
>
> -Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef