Order-flow software is not uniformly demanding. Most of the load comes from a small number of visible elements: the count of rows on screen, the number of panels updating at once, and the depth of history loaded into memory. Understanding which resource each element consumes turns performance tuning from guesswork into a short checklist.
Where the Work Goes
Rendering a footprint chart is primarily a text-layout problem. Each visible cell contains at least two numbers, and the layout engine must measure and place them every time the chart is redrawn. A chart with twenty thousand cells is therefore expensive even though the arithmetic behind it is trivial. Reducing visible cells — fewer bars, fewer rows per bar, or both — is the most effective single change available.
Depth panels are different. They update frequently and each update can reorder rows, so the cost is dominated by the update rate rather than by the amount of data displayed. Throttling the update rate often improves perceived smoothness more than any hardware change.
Memory and History Depth
Historical bars are held in memory for the visible range plus a margin. A large margin speeds up scrolling but increases the footprint. On a machine with limited memory, an aggressive margin causes paging, which appears as intermittent stalls when the chart is scrolled quickly. Reduce the margin before adding memory; the default is usually larger than necessary.
The local store on disk is a separate concern. A store with millions of trades per instrument is normal; a store that has never been pruned is not. Indexing time grows with the number of sessions retained, and that is what makes a chart slow to open in the morning. Prune on a schedule and verify the index afterward.
| Symptom | Likely cause | First check |
|---|---|---|
| Slow chart open | Large index or deep history | Retention window and store size |
| Stutter while scrolling | Memory margin too large | Visible bar count and cache margin |
| Lag during replay | Multiplier above render capacity | Replay speed and visible panels |
| Ladder flicker | Update rate too high | Depth throttle setting |
| Gradual slowdown | Panel count or module count | Number of updating panels |
| Fan noise under load | CPU-bound text layout | Rows per bar and bar count |
CPU, GPU, and Storage
Chart rendering is mostly CPU-bound because of text layout. A GPU helps with compositing and with large filled areas such as heatmaps, but it will not rescue a chart that is laying out tens of thousands of text cells. Prefer a processor with strong single-thread performance before investing in a graphics card.
Storage matters mainly at startup and when seeking in replay. A solid-state drive reduces the time to open a long history and the pause when jumping to a distant date. Once the data is in memory, storage has little effect on frame rate. This is why a faster drive improves the morning experience but not the middle of the session.
A Simple Benchmark Method
Choose a fixed chart configuration and a fixed replay range, then measure the time to complete the replay at a defined multiplier. Repeat three times and record the median. Change one setting and repeat. This method is crude but comparable across machines, and it prevents the common mistake of attributing an improvement to the wrong change.
Record the configuration alongside the result: instrument, bar count, rows per bar, panel count, and multiplier. A number without its configuration is not a benchmark; it is an anecdote. Keep the log inside the workspace directory so the next comparison starts from a known baseline.
When to Change Hardware
Change hardware when a measured bottleneck persists after configuration has been reduced to a sensible baseline. Do not change hardware to compensate for a chart that is displaying a month of rows at maximum density. The first is a capacity decision; the second is a configuration decision wearing a hardware costume.
For most single-screen workspaces, a modern four-core processor, sixteen gigabytes of memory, and a solid-state drive are sufficient. Multi-monitor workspaces with several updating panels benefit from more memory and from a graphics card that can composite the desktop without stealing cycles from the processor. Beyond that, the benefit falls off quickly relative to the cost of the hardware change.
Housekeeping That Helps
- Close panels that are not being read; hidden panels can still update.
- Reduce the number of instruments in the active group.
- Prune the local store on a fixed schedule.
- Keep one recovery workspace that uses minimal panels for slow mornings.
These four habits solve most reported performance problems without any change to the machine.