Support Board
Date/Time: Mon, 25 May 2026 18:18:49 +0000
Post From: FAST DOM can it even be done in Sierra Chart?
| [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 |