eliminating some weak array creations

[nilsbecker]

i noticed that my simulation-minibenchmarks spent most of their time in weak array creation and garbage collection. here is a naive attempt at reducing this load.

the result is that overhanging weak arrays stay around but will be collected whenever it's convenient. it seems that within react.ml, having weak arrays longer than Wa.len says, is not a problem. Wa.t is not public so there should not be a problem for clients

the tests in test.ml pass. also, in one mini-benchmark,
https://gist.github.com/nilsbecker/2ec8d0a136e2fcc20184#file-react_minibenchmark-ml
this version is up to 20% faster

i am not sure if the Wa.clear is needed on finish. anyway, the whole thing is pretty much a stab in the dark, so could be nonsense.

[dbuenzli]

Will need to have a closer look at this but don't have the time at the moment. But my first gut reaction is that this may have a bad impact when used with js_of_ocaml where weak arrays are not. Still it's nice to have isolated that bottleneck but I will have to see if you are not dealing with a pathological case.

[nilsbecker]

sure. my use case is probably relatively extreme since it measures almost only overhead from mini-events. but maybe others have similar use cases? have not tried any js version

[dbuenzli]

As you can see Wa.clear is used in other cases (e.g. node stops) where its important to keep that behaviour for the js backend, so that we leak less. But I think that what you propose is ok for the update step, since the whole step datastructure should be quickly gc'd. Could you maybe try to change your patch to only affect this line and see if you get similar speedups.

[nilsbecker]

i tried. changing only finish in Step.execute while leaving Wa.clear untouched does not give a noticeable speedup.

[nilsbecker]

however, the other way around, changing only Wa.clear does speed it up the same, and test.ml still succeeds.