Heuristic memoisation for state objects

[dphfox]

Right now, state objects unconditionally memoise their contents, which can build up memory usage when dealing with a large sea of small state objects dealing with lightweight primitive values. For primitive values which can be easily garbage collected, when generated by a process which is lightweight and fast to run, we should disable caching and similarity checks, so values can quickly flow down hot paths.

[xiyler]

Since I implemented something similar to this in my library, I would like to believe that my insight is somewhat valuable to this discussion. While the concepts behind my implementation are heavily borrowed from Boatbombers' PR, the implementation is entirely different and is actually semi-generic for all state objects.

I believe there are only three possible cases that conditional memoisation is actually concerned with, which are:

1. The state object has other types of objects as dependents. It doesn't matter if there is an Observer there as well, as such, it's not safe to release the value.
2. The state object has only Observers as dependents, as such, it's entirely safe to release the value after the observers' listeners are ran. However, this case is slightly more complicated for Fusion than Vinum since Fusion runs Listeners in new coroutines, which means the question whether it should concern itself with yielding and all of its gotchas is important to answer.
3. The state object has no dependents at all. While it's tempting to also release the value here, its actually worse for performance when you do such a thing since usually state objects that have no dependent are often read by loops (like RenderStepped). Plus, denying to release the value here somewhat makes the "goal" of the optimization perhaps clearer? As in, this optimization enables Computeds (and Deriveds in my library) to act like "Flow" objects where their main concern is to just "pass" values to Observers.

I believe supporting these three cases actually accounts for all possible scenarios (of course, this is limited by how Fusion will handle the complications that are present because of yielding), and usually eliminates the need for recomputing on reading.

Plus, I also think the "best" place for actually all of this "conditional-value-releasing" stuff is actually in updateAll after all objects have recaptured their dependencies, so when we loop again through the queue, we actually decide based on the new dependents. However, this may not apply to SETS as much as it applies to the algorithm I use for Vinum's updates dispatching.

...and I think that's all what I got. Hope this helps :)