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

[Nils Becker <nils.becker@bioquant.uni-heidelberg.de>]

thanks daniel,

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

yes, it's wide at the primitive level. initially i did have an E.select
over O(N) events somewhere which slowed it down a lot, but that is
already repaired, as you explain. right now, i should not have any
combinators that filter out a lot of unneccessary dependencies, so that
should be fine.

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

so i guess i need to make the update chains a short as possible. at the
moment, i update the external heap by events which produce (heap ->
heap) updater functions; they each have exactly one daughter event in
which the function is applied to the actual heap. this structure is just
a by-product of how i initialize the simulation. i guess by streamlining
this into just one event i could potentially shorten the dependency
chain and speed it up?

> Is your code published somewhere ?

no, it's pretty messy still. if you'd like to have a look i could put it
on bitbucket..

n.