No attempt has been made to optimise the performance of the market data handlers.
We should commit some baseline benchmarks, and profile the code to see where the hot spots are.
There is some good guidance to Rust performance optimisation in the perf-book:
https://nnethercote.github.io/perf-book/introduction.html
serde_json deserialisation is likely the bottleneck here; but I'm also interested to understand the performance characteristics of tokio::spawn_blocking vs thread::spawn (as opposed to what we are currently doing with tokio::spawn)
We are also doing lots of unnecessary Arc<HashMap<Instrument, WebsocketSubscription>> lookups on each market data event to populate the MarketData.Instrument field.
As there are no immediate plans to build a cross-exchange symbol map; we can probably just replace the Instrument type with the symbol ticker String, and save a bunch of locks and HashMap lookups.
No attempt has been made to optimise the performance of the market data handlers.
We should commit some baseline benchmarks, and profile the code to see where the hot spots are.
There is some good guidance to Rust performance optimisation in the
perf-book:https://nnethercote.github.io/perf-book/introduction.html
serde_jsondeserialisation is likely the bottleneck here; but I'm also interested to understand the performance characteristics oftokio::spawn_blockingvsthread::spawn(as opposed to what we are currently doing withtokio::spawn)We are also doing lots of unnecessary
Arc<HashMap<Instrument, WebsocketSubscription>>lookups on each market data event to populate theMarketData.Instrumentfield.As there are no immediate plans to build a cross-exchange symbol map; we can probably just replace the
Instrumenttype with the symbol tickerString, and save a bunch of locks andHashMaplookups.