[Events Orderbook] Implement copy on write for latest auction state

[nlordell]

The streamed orderbook works by keeping a "confirmed" auction state that only includes confirmed events that are unlikely to ever change because of reorgs, and a "latest" state that include events up until the latest block.

The "latest" state currently is calculated by doing a deep clone of the "confirmed" state and then applying the events between the confirmed block and the latest block. Because of potential reorgs, the "latest" state needs to be rebuilt on every update, which includes the deep clone of the "confirmed" state. This is inefficient given that there are usually a relatively small number of "latest" events that only affect a small part of the state.

This issue captures an enhancement to implement copy on write semantics for the auction state where the "latest" state will keep only a shallow copy of the data until a part needs to be modified, at which point it will do a deep clone of only that account/order/pendingwithdrawal/etc. This will allow the "latest" state to be created much more efficiently and avoid unnecessary deep clones.

[fleupold]

Do we know how long the deep copy actually takes (e.g. compared to fetching the events since the last confirmed block)? This would help us prfioritize this task.

[nlordell]

Do we know how long the deep copy actually takes (e.g. compared to fetching the events since the last confirmed block)?

I imagine it is a very small amount of time, I don't even see a spike in my CPU usage when doing an update. I can get some numbers if you like.

This would help us prfioritize this task.

I definitely do not think this is a priority. I think the biggest issue this causes is it allocates and throws out a lot of garbage, which may eventually cause longer garbage collection cycles periodically. I think given the scale of our price estimator service, I don't imagine this being an immediate issue.

[fleupold]

My concern is if this is worth doing at all.

[nlordell]

update: Ran an unscientific benchmark like so:

const start = require("perf_hooks").performance.now()
for (let i = 0; i < 1000; i++) {
  (orderbook as any).confirmedState.copy()
}
console.log(require("perf_hooks").performance.now() - start)

And it took 9358.11694300174ms, so roughly 10ms per copy.

I think in the long term it might be a nice optimization and I don't think it would be too much work. It would also allow us to lazily apply events on query and change which events get applied, depending on whether we want the open or the finalized orderbook.