Order-flow software is memory-bound before it is compute-bound. The dominant costs in ATAS come from holding tick history, expanding footprint rows, and drawing many panels at once — in that order, in most configurations.
01 Where the cost actually sits
Three budgets compete. The tick store holds recorded prints and, if book recording is enabled, depth snapshots. The aggregation cache holds the derived series each panel needs. The render budget is what is left for drawing frames. A machine that is comfortable with six clock charts can be uncomfortable with two footprint charts, because the row arrays dominate the second case.
| Centre | Scales with | Dominant remedy |
|---|---|---|
| Tick store | Session count and depth recording | Retention policy |
| Aggregation cache | Panels × series length | Fewer panels per workspace |
| Footprint rows | Bars × rows per bar | Larger row multiplier or tick count |
| Frame time | Visible instances and effects | Reduce animated effects |
02 Memory budget per panel
A practical planning rule is to give each footprint panel a memory allowance proportional to the number of bars visible times the number of rows per bar, then reserve the remainder for the tick store and the operating system. The rule is approximate, but it is enough to decide how many panels fit on a given machine without repeated guessing.
- Count visible bars, not stored bars; the cache is window-driven.
- Multiply by rows per bar; that product is the row array size.
- Add one allowance per instance for its derived series.
- Reserve at least a third of memory for the store and the system.
03 Recorded data and disk throughput
Replay reads recorded data continuously. A tape with modest throughput will make replay stutter even when the machine has plenty of memory, because the read path cannot keep the playback buffer filled. Depth recording multiplies the write volume substantially and should be reserved for sessions that will actually be replayed.
Replay that pauses at the same point in a session, every time, is a read-throughput symptom rather than a rendering one. Change the storage location before changing any display setting.
04 Displays, scaling and pixel cost
Two displays at high density carry more pixels than four older ones, and the renderer pays for the pixels, not the physical count. Scaling the interface up to stay legible costs frame time in the same way that adding a panel does. When a layout is moved to a denser display, expect to reduce either the number of visible rows per bar or the number of animated effects.
| Layout | Panels | Relative load |
|---|---|---|
| Single chart, one instance | 1 | Baseline |
| Chart plus ladder | 2 | ~1.6× |
| Four-panel desk | 4 | ~3× |
| Eight-panel desk with replay | 8 | ~6× |
05 A sizing procedure that ends arguments
Measure before adding. Open the intended workspace, enable the heaviest indicator set that will actually be used, then run replay at the intended speed while scrolling. If that is smooth, the machine is sized for the workload; if it is not, reduce one variable at a time, starting with animated effects, then rows per bar, then panel count. Record which of the three was reduced, because the same three variables return every time the layout grows.
The rendering levers referenced here are described in detail on the themes and rendering page, and the recorded-data side belongs to replay and data feeds.