Coder Social home page Coder Social logo

minicheddar / crypto-stream Goto Github PK

View Code? Open in Web Editor NEW
4.0 4.0 1.0 1.05 MB

High performance market data handlers for cryptocurrency exchanges

License: MIT License

Rust 100.00%
binance ccxt coinbase cryptocurrency exchange gate-io huobi kraken okx websocket

crypto-stream's People

Contributors

minicheddar avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar

Forkers

tang72698104

crypto-stream's Issues

Compare performance between data types used for Price

Rust does not allow ordering of f32/f64s as part of std. This prevents using f64 as a key in BTreeMap<f64, OrderbookLevel>.

For now, we should just use this (https://crates.io/crates/ordered-float), but I'm curious on the performance difference between.

  • Implementing PartialOrd for floats as above
  • Having serde deserialise 'float-like' data straight to Decimal
  • Having serde deserialise to f64, but converting to Decimal when returning MarketDataKind:L2Update/Snapshot
  • Storing prices as u64 with a mantissa on the number of floating points as a separate piece of metadata (like smart contracts)

This is definitely a low-priority premature micro-optimisation!

Factor out common exchange integration code

Each exchange connector has been (deliberately) duplicated to expedite development speed.

Once the initial set of exchanges have been implemented, there may be an opportunity to break out common integration code to a re-usable set of components.

Commit baseline performance benchmark + profile code

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.