Handle large amounts of signal history

[maxfrigge]

The state tree becomes quite slow when it keeps history of large amounts of signals. By large amounts I mean over 1k signals. Would be really cool if the debugger could handle these cases too.

The way the debugger works right now is, that it reruns all signals with the previous input to reproduce state when time traveling. This means that you can't just limit the number of signals to keep history for.

I currently see these approaches:

1. Keep a snapshot of the state every N signals and at some point purge older signals. The debugger could then use the snapshot as a base for all state mutations when rerunning signals.
2. Use a storage engine to manage the older signals instead of keeping them all in state - this could be local storage, web sql, index db.
3. A combination of 1 and 2 :)

[christianalfoni]

Adding some notes from hangout:

- Split events
- Baobab problem
- Snapshot
- Do not show inputs and outputs

[christianalfoni]

Will make some suggestions on what we can do here :-)

[maxfrigge]

Just to make sure. By split events you mean send all controller events (with cleaned payload) to the debugger and then separately send it the signal definition on init?

[christianalfoni]

Actually I did not mean cleaning them, though that is also a good point. Though I am wondering if latest changes has made a huge difference? There were a couple of bad bugs there related to performance :)

[maxfrigge]

Haven't tried it yet. Will do asap and get back with results.