Allow squashing history entries

[ds300]

rationale

When updating things in the store, we make potentially many changes to different atoms. our history atom is updated once per .put and once per .remove call, but if nobody reads the history during a transaction we may be creating more history entries than we need. They can be trivially squashed, but we don't currently know when it's safe to do so.

proposal

First let's define the notion of a 'fresh read': the first read to happen after an atom was last changed.

Now let's say we keep track of the lastFreshReadEpoch for each atom and derivation.

On every fresh read (after the initial one?), before exposing the state or history of the derivable, we can squash down any history events since the lastFreshReadEpoch.

impact

This would be a fairly minor perf improvement for very niche use cases. In some situations it may be a big perf win, but I'm struggling to think of what those cases may look like.

[judicaelandria]

In the case of Tldraw, I think it's not safe to squash history, you may always want to revisit them! I definitely agree that this is maybe a big perf win but not really safe! but maybe I am missing something in this context.

[ds300]

I suspect you're thinking of the user undo/redo history? That would be important to preserve yeah. But this issue is just referring to the signal's internal diff history, which is only used for incremental recomputation, and doesn't need to be 'undone' at any point. I think it should be possible to squash it safely in some situations, but it's not a priority since it would add complexity and not much performance.