Because we're in the browser, timing is noisy and unreliable. Any one timing figure can be too high because of background activity. For example, on one occasion a subscription might run in 1ms but on the next occasion it might take 5ms because the browser decided to pause for a partial GC. If you see the 5ms figure, you can be fooled into thinking there's a performance problem in the subscription where, in fact, its just an environment-caused anomaly.

For accurate timings, you have to run the same action, say, 50 times and then take the best figure (the mean is useless because it will be distorted by the random poor results which happen when the browser pauses to go off and do something else).

All of which leads to the following blue sky idea ...

Under user control, re-frame-trace could replay an event 50 times, resetting app-db each time back to the original value, so we get 50 identical trace outputs. By finding the best outcome for each part of the trace, it could then provide much more accurate timings, by removing all the bounce.

Notes

• the user would have to specifically ask for this to happen. Might take a quite a few seconds to run 50 repetitions. User would have to somehow put the application into the right state and then maybe tell re-frame-trace what event to dispatch? Maybe they just say to redo the last event (but how then do we know what value app-db had before the last event?
• will the trace for each of the 50 runs actually be identical? Could there be non-determinism because of the timings around animation-frames, maybe?
• we're still measuring dev builds, not prod builds.

Implementation

There will be some tricky implementation issues to solve. Each of the 50 iterations involves resetting app-db to the original value and re-dispatch-ing the event again:

1. how do we know when we have captured all the trace caused by a single event? At any point there might be more work queued for the next animation frame. See Knowing when "an epoch" has finished #114
2. closely related to point 1, how do we know when we should do the reset of app-db and do another iteration.
3. when we do reset app-db we want to stop capturing trace - the going backwards bit is not interesting
4. related again to point 1, how do we know when the reset of app-db has stopped propagating? We can't turn on tracing capture and re-dispatch until the effects of the reset have stopped happening.