It absolutely won't improve and because you can't use native floating point calculations or you end up with rounding errors, which would be detrimental in anything finance, you have to use a software based library to eliminate rounding errors. This is substantially less performance, but that's not even the whole issue caused by too fine granularity in prices. The real issue is sorting price level queues (not the queue at each price level), but just the price levels themselves. When you have such insignificantly small price increments, algos will use the tiny incremental price improvements jump the queue (much like payment for order flow uses tenth of a cent increments, but in this case it will be an exchange with each one improving the price by 0.00000000000001), which means you're going to have an insane number of price levels that need to be sorted, but also you're going to effectively be flooded with quotes non-stop. Algos will just leap frog eachother by these insignificant amounts. Each time that happens and a new price level is created, it needs to be inserted and sorted. That said, specific exchange policies / restrictions on quotes could be adopted to deal this issue (I have some in mind that would solve these issues -- I thought about this a bit since my earlier post). A simple example of a policy/restriction to deal with this is that a single participant can't have more than X bids and Y asks at a time. This actually is OK because I read the exchange website that said it was going to use random allocation at each price level, so there's little incentive to be the first at a particular level. This would limit the number of price levels to X*Y*number of participants on a particular symbol, which is then reasonably sorted efficiently because you're not likely to have millions of participants on a single underlying near the money (provided X*Y is reasonably low of course). This won't stop the leap frogging, but it will reduce the number of price levels that need to be sorted. Could also limit the number of participants on a specific symbol, but then how do you decide who is allowed to participate? Violates the whole open concept of the exchange. I would not recommend rate limits on orders because the intention here is algo trading and algos traders won't like restrictions on how quickly they can get out of a bad position for example, but maybe with a rate over X time, it wouldn't be so bad. As long as they weren't intentionally running near the limit, or maybe there's a separate limit for orders that would result in closing a position. Without a limit of number of bids and asks per participant, you risk a malicious participant from DOSing the exchange by submitting millions of orders at different price levels (they wouldn't even have to do this quickly, just having the price levels exist would cause sorting to degrade in performance). Sure you could just remove that participant from the exchange, but that will only be reactionary unless some limit is in place. Still, don't underestimate the creativity of malicious actors -- especially if they can somehow use this for profit.
@Lee- , outstanding comment!!! Thank you. I'm building the order book, bid/ask ladders, and matching engine for Ritchie. This post is epic, and definitely changed my implementation plan. Could I impose upon you to be a beta tester?
Yes, rounding error can drive everyone cray-ZEE. That's why I'm using the Intel financial decimal library: https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library
I remember you mentioning your exchange months ago and you had my interest. Whether you need beta testers or want someone to try to find exploitable issues, I'll be interested in assisting. Whether I'll have the availability at that time I can't say for sure. Anyway send me a PM when the time comes and we'll see.
Hehe, it's a technical flaw in the film. They are showing Apple Macintosh screens, but the disk is being inserted into a P.C.