Support Board
Date/Time: Mon, 25 May 2026 17:27:15 +0000
FAST DOM can it even be done in Sierra Chart?
View Count: 63
| [2026-05-25 13:11:36] |
| TopGunTrader - Posts: 309 |
|
Hi, I have developed studies that are beyond amazing and in testing run fine by themselves but on fast 10ms refresh DOM order entry and with other studies Sierra Chart always lags, orders show up 1/2 to 3 seconds late, cancels don't go away but I see on another Sierra chart with no studies they are gone, same with moving etc. It's so bad I investigated writing a Stand alone DOM in C++ Windows app connecting to you with DTC. Problem is the data, dom depth etc due to CME restrictions doesn't come through so this is also NOT a possibility. There HAS to be a way to have advanced studies updating frequently AND for Sierra order execution to be lightening fast and responsive! I see no reason not to have powerful tools AND speed. Each study should have own path to drawing and one doesn't lag another. Please tell me you have SOME solution to this problem I can't trade the way I need to as I now understand Sierra Chart and these lag spikes have cost me so many dozens of times in losses. ONE chart up with 2-3 studies should lag 1-3 seconds in moving an order or visually showing where order is or if its even active or not. -------------------- Yes, roughly: Sierra is not giving every study its own independent high-priority render lane. In practical terms, the lag usually comes from this chain: Market/order event arrives Sierra receives trade/order/depth updates internally. Chart/Trade DOM update cycle runs Sierra schedules chart updates based on its chart update interval, DOM update behavior, internal message loop, and whatever work is pending. ACSIL studies execute on the chart Your studies run as part of the chart update path. If several studies are loaded, they effectively share that update cycle. A heavy study, lots of drawings, GDI work, file/log work, cross-chart calls, or order-management logic can delay the rest of the visible update. Drawings are processed sc.UseTool, study subgraphs, custom GDI, text labels, rectangles, order overlays, DOM columns, etc. all have to be reconciled into what Sierra will display. Screen repaints Only after that does the visual representation show the updated order, removed order, moved order, etc. So the important point is: Your order may already be accepted/canceled internally, but the visible DOM representation can lag because the UI/drawing pipeline has not caught up. That is why you see orders “show up late” or “disappear late.” It does not always mean the broker/Sierra order state is late. Sometimes it means the visual confirmation is late. The killer issue for your setup is that the Trade DOM is sharing the same environment with: ACSIL studies chart drawings DOM drawing custom GDI overlays order overlays cross-chart references logging recalculation guards Windows message pump timing So yes, if one study is doing too much per update, it can make the DOM visually stale. My best mental model: Sierra internal order state faster | v ACSIL/chart update cycle slower under load | v Trade DOM visual redraw slowest when drawings/studies are heavy This is exactly why an external order panel can still help even without external market data: it can send cancels/orders through DTC while Sierra’s visual DOM is catching up. But it cannot fully replace the DOM visually unless it gets its own market data/depth feed |
| [2026-05-25 13:12:46] |
| TopGunTrader - Posts: 309 |
|
Honestly, Sierra should offer a separated low-latency trading/UI architecture for power users. The core problem is that fast order handling, DOM rendering, ACSIL studies, chart drawings, GDI overlays, and custom tools are too entangled. For users like you, Sierra should provide a mode where orders and cancels are never waiting behind chart drawing work. What Sierra should build: Dedicated Order Thread Order submit/cancel/modify should run on a protected high-priority path, separate from chart redraws and study calculations. Dedicated DOM Rendering Thread The Trade DOM should not be blocked by chart studies, GDI overlays, or sc.UseTool drawing load. Separate ACSIL Drawing Budget Let studies draw, but cap or schedule them so they cannot starve order/DOM updates. Order State Priority Lane Working order add/remove/move visuals should update before non-critical drawings. If an order is canceled, the DOM should reflect “cancel requested” immediately, even before final confirmation. Native Fast Drawing API Sierra should expose a modern retained-mode drawing layer, not force heavy UseTool updates or awkward GDI overlays for dense tools. Per-Study Performance Telemetry Show exactly which study is consuming update time: calculation milliseconds drawing milliseconds number of drawings adjusted GDI callback time skipped frames order-overlay delay Study Isolation One slow/heavy study should not make the entire chart/DOM feel sticky. At minimum, Sierra should allow studies to run on worker threads when they are read-only/data-prep only. DOM-First Mode A setting like: “Prioritize order entry and Trade DOM updates over all custom drawing/study rendering.” That mode should guarantee this order: 1. receive order/depth update 2. process cancel/modify/submit 3. update order state visuals 4. update DOM price/depth visuals 5. run lower-priority chart drawings/studies The blunt version: Sierra is incredibly powerful, but it still behaves like a single highly-loaded workstation app. People doing dense ACSIL/GDI/order-management work need something closer to a trading terminal engine with strict priority lanes. If Sierra gave us order thread isolation + DOM render isolation + study performance telemetry, your current project probably would not need to exist. |
| [2026-05-25 15:00:35] |
| User150671 - Posts: 75 |
|
I use two separate instances of Sierra, one for DOMS one for Charting. DOMs instance is just DOMs for 9 markets. DOMs set to 20ms to 50ms update depending on market (this is faster than eye can see, so fine for execution). Unless you need to have everything in the one instance, it might be worth giving such a setup a go and seeing if your performance issues continue. Obviously if you do need everything that is heavy in your charts in the same instance as your DOMs this is not really an option - either way this would be a workaround not a fix to the issues you describe. |
| [2026-05-25 15:46:57] |
| User431178 - Posts: 874 |
|
Agree with other user suggestion about separate minimal instance for fast DOMs, can definitely help a lot. I have developed studies that are beyond amazing and in testing run fine by themselves but on fast 10ms refresh DOM order entry and with other studies Sierra Chart always lags, orders show up 1/2 to 3 seconds late, cancels don't go away but I see on another Sierra chart with no studies they are gone, same with moving etc. Have you profiled your study code to determine where the lag is actually occurring? If Sierra Chart is responsive with the studies disabled and becomes unresponsive when they're enabled, that would suggest the first place to investigate is the study code itself. For the DOM, what is your Chart Drawing Time in Milliseconds and Average Calculation And Draw Time in Milliseconds in chart settings? Also, what happens in your code when an order is submitted/modified/cancelled? Does those events trigger any additional calculations, drawing updates, cross-chart processing, file I/O, logging, or similar work in your studies? |
| [2026-05-25 16:07:25] |
| joshtrader - Posts: 550 |
|
The SC DOM is the fastest one out there, period. But you can't run it alongside other charts which all share an update thread and expect it to be as fast. Sierra has for 15+ years been very stable, largely due to the fact that they have a largely single threaded model (excluding background threads which update data on a chartbook load, etc.). Use a separate SC instance. |
To post a message in this thread, you need to log in with your Sierra Chart account: