Latency and speed
The real, measured speed numbers for Lune, and how event-driven, in-memory execution keeps them low.
Lune executes fast because it is event-driven and works in memory. This page gives the real, measured numbers and explains how Lune keeps them low.
What the numbers mean#
Every number below is measured, not a marketing figure. Lune-side processing is the time inside Lune, from receiving a signal to sending an order to your broker. Broker fill time is added by the broker itself and sits outside Lune's control.
Lune-side processing5 to 10 ms (p50 = 5 ms)OptionalThe time inside Lune, from signal in to broker dispatch. Half of runs finish in about 5 ms.
Broker fill (market order)3 to 5 ms p50OptionalExtra time the broker takes to fill a market order after Lune sends it.
Copy closep50 = 18 msOptionalLeader broker event to follower close, half of runs at about 18 ms.
Copy entryp50 = 74 msOptionalLeader broker event to follower entry, half of runs at about 74 ms. This is Lune dispatch plus broker fill time.
A copy close is faster than a copy entry because a close is simpler to route to the follower. Both numbers include the broker's own fill time, not just Lune's work.
How Lune stays fast#
Speed comes from the design, not from adjectives.
- Event-driven, not polling. Lune reacts to broker and signal events the moment they arrive, instead of asking on a timer. There is no wait between checks.
- In-memory work. Lune holds live state in memory and acts on it directly, so it does not round-trip to a database on the hot path.
- Parallel copying. A copy group processes up to 25 followers in parallel, so replication stays quick as you add accounts. A flatten command dispatches to up to 50 accounts in parallel.
What speed does not remove#
Latency is one part of a fill. The market still has to have a price for your order, and a limit order still fills only at your price or better. Speed reduces slippage, but it does not guarantee a fill at a specific price. See Order types.