Re: [Caml-list] using React for -- reactions

["Daniel Bünzli" <daniel.buenzli@erratique.ch>]

Le mardi, 19 août 2014 à 09:34, becker.nils@gmx.net a écrit :
> is there a run-time cost for large dependency graphs?

The runtime cost is depends on the topology of the graph rather than its largeness. Basically given a primitive event/signal update you need in the worst case to do a topological sort of its recursive dependencies on each update step. But that's really the worst case, as for example if a signal doesn't change its value in the step it's dependents are not updated.  

> reactions are relatively sparse, ie. the number of reactions R=O(N),
> where N could be from 1e1 to 1e4 or so. so, in each update step only a
> small number <10 of dependent molecule numbers and waiting times need to
> be updated, even for large systems. in other words, the React-managed
> dependency graph is wide (N) but not tall (relatively short dependecy
> chains, see above),

If it's wide at the *primitive* level then this is a good property for performance since an update will have little needless work to do. If it is wide just *after* the primitive for no good reason, i.e. single primitive with huge number of dependents that filter the primitive and then short dependencies, you may want to express the first level of dependents as a primitive if the filtering nodes entails that only a few of them trigger on an update. That is sometimes you can gain performance by putting more logic/transformation in your primitives, as it allows you to cut down on the number of nodes or needless updates.

> bottom line: can a React based simulation possibly compete with manual,
> in-place update of arrays, let's say within a factor of 2? if yes what
> do i need to pay attention to?

No idea. Basically you need to pay attention to the topology of your graph. Is your code published somewhere ?  

Best,

Daniel