That will be amazing!!! 
rupurt
lud
Do you need to continuously try to match orders ? I would assume that you’d only have to match new orders with existing ones once and then handle matches and store the order with remaining quantity.
0
chrism2671
Oh hey @rupurt! 
So I actually did knock this up with a map, and left it in such a way that it can be refactored as an ETS table! This is interesting though, I might just go-ahead and change it to ETS. I’m actually surprised there was so much difference, I’d have expected Map to be equally quick (heck, it’s surprising to me that Map isn’t ETS under-the-hood, but then again, maybe I don’t know enough about BEAM to understand why it isn’t).
I read that most high performance orderbooks are done with AVL trees. The closest native thing is gb_trees in Erlang, which should do the trick.
1
dom
rupurt
The link posted by @dom is exactly what pushed me to try out the ETS implementation. The gb_trees data structure sounds interesting but there’s no information on it’s doc page as to whether or not it’s stored in ETS. I’m going to assume that it’s not stored in ETS as other data structures such as digraph do mention it digraph — OTP 29.0.2 (stdlib 8.0.1).
0
entone
You have a few other options as well. The creator of Hackney has some great bindings for RocksDB barrel-db / erlang-rocksdb · GitLab a wicked fast and stable KV store from Facebook.
If you want to go full on distributed, Riak Core could be an option GitHub - basho/riak_core: Distributed systems infrastructure used by Riak. · GitHub
and there’s also plum_db based on Partisan and Riak, Leapsight OSS / plum_db · GitLab
0
sasajuric
Author of Elixir In Action
You’re using ordered set which is relatively slow compared to other types. Could you use regular set? Also if the table is accessed from other processes, provide the read_concurrency: true option (but in your case you don’t need write_concurrency, b/c the table is protected, so it’s written to from a single process.
You already answered it yourself:
So basically, measure twice, cut once
Can you elaborate why? I’d be surprised if that solution would be significantly faster than ETS, if faster at all, b/c I think (but not completely sure) that the same limitations apply (data still has to be copied in/out).
0
dimitarvp
I have lost the links to several Map implementations in pure Rust and now can’t answer factually. Sorry about that. I seem to remember that one of them could have managed without copying – only the return values of the functions for fetching and putting values from/to the Map.
You’re very likely correct that it won’t be an improvement over ETS though. I’d try it it if I had the free time but can’t claim anything for a fact currently.
0
rupurt
Another job for configurable order book adapters! 
For my particular case I need to read the first N values from each set. If I was to use a regular set I would have to read all of the values from each set, order them, then take the first N values. I would assume that would have similar performance characteristics to the Map implementation.
0
sasajuric
Author of Elixir In Action
Could you explain the exact scenario in more details, so we can consider if there’s some opportunity to reframe the implementation so that it doesn’t require an ordered set?
1