I'm currently thinking about "tracing" deltas through update functions in our elm-like apps again.
Basically all our collections would need to maintain two additional things. E.g. HashSet would need to new fields
basedOn : HashSet<'T>
deltas : seq<SetOperation<'T>
Whenever Adaptify sees those things it could check if the basedOn happens to be the current state of the output and (when successful) apply the deltas to it.
After that it would need to "destroy" both fields, which could be done by replacing them in the immutable model or by mutating them under the hood.
The latter would certainly perform better but it may also cause many problems (threading, etc)
Since computeDelta uses reference-equality on subtrees (for HashMap/HashSet/etc.) this will most likely not improve the performance drastically, but we should investigate that eventually...
@haraldsteinlechner
keeping deltas aside immutable update: we had some sketches some years back. while looking for it i found this folder: https://github.com/aardvark-platform/aardvark.base/blob/master/src/Demo/Sketch/UndoRedo.fsx
I'm currently thinking about "tracing" deltas through update functions in our elm-like apps again.
Basically all our collections would need to maintain two additional things. E.g. HashSet would need to new fields
Whenever Adaptify sees those things it could check if the basedOn happens to be the current state of the output and (when successful) apply the deltas to it.
After that it would need to "destroy" both fields, which could be done by replacing them in the immutable model or by mutating them under the hood.
The latter would certainly perform better but it may also cause many problems (threading, etc)
Since
computeDeltauses reference-equality on subtrees (for HashMap/HashSet/etc.) this will most likely not improve the performance drastically, but we should investigate that eventually...@haraldsteinlechner