Support Board
Date/Time: Tue, 28 Jul 2026 03:57:52 +0000
Rendering problems in subinstance
View Count: 292
| [2026-06-10 13:06:06] |
| User512353 - Posts: 159 |
|
Hardware: Intel 12700K CPU, using internal GPU, one 4k monitor attached OS: Debian 13.5, GNOME 48, 9 fixed workspaces, wine 11.0 SC2915 I have a chartbook that does some heavy calculations involving multiple spreadsheets, but with a modest chart update interval of 250ms. When I load this chartbook in the Main Instance of SC, it works well with good responsiveness. When I load this chartbook in a sub-instance, performance degrades massively: The 8 charts in the chartbook update normally, but the detached trade windows, the spreadsheets, and the status bar, draw extremely slowly, like 3-4 seconds per widget. The complete rendering takes minutes. And mouse actions on any window/widget are extremely slow. The very slow redraw occurs with every switch to the workspace. And when there is no data stream, i.e. in the one hour after session close, the problem does not show! I checked CPU and GPU performance while the problem shows, i.e. when switching to the workspace. There is no observable CPU or GPU bottleneck. Total CPU utilization is 10-15%, p-cores <70%, e-cores <10%, GPU renderer <7%. I have used this chartbook in earlier SC versions in sub-instances with no such problems - as far as I can remember. However, one thing that is new now: This is not the only SC Main instance that uses sub-instances. It is in fact the second Main instance with DTC protocol server ports set to 11097 ans 11096. Not sure if that plays a role, but maybe it is worth mentioning. Any idea what the problem is? |
| [2026-06-10 15:06:26] |
| John - SC Support - Posts: 47358 |
|
Do you have any other chartbooks open in the sub-instance where this is occurring? Also, you should look for items that might be slowing down that instance for some reason. I happened to be doing some testing in which I need a "Current Bid Volume" column in my DOM. It was there for a few days and one day I was having trouble with that instance running very poorly. I tried a number of items to clear things up, but nothing worked. I eventually loaded a different chartbook and everything was fine. I realized that the accumulation of the data in that column was the culprit. The point being that there can be things that are in your chartbook that can cause trouble over time. Dense data in the DOM, transparencies, etc. Be sure to look for these as well, as you may not have them occurring when you move the chartbook to another instance. For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2026-06-10 17:36:18] |
| User512353 - Posts: 159 |
|
It is the only chartbook in the sub-instance. There is no chart-DOM or trading-DOM open in the chartbook, no t&s window either. As far as I can quickly overview this, there are no transparencies in the chartbook, and definitely no CPU-heavy studies like VbP or TPO. The spreadsheets do heavy calculations, I think about 1000 rows. However, all this does not explain why the problem only shows up in the sub-instance. From my observation that the problem disappears when the data stream ends at 16:00 central time, plus the fact that no CPU or GPU stress is observed, (plus my 30+ years professional programming experience :-)), I would conclude that there is a problem somewhere in the concurrent execution of the DTC client and the graphics renderer, where either something is repeatedly stalled waiting on some semaphore or something like that, or the rendering process for some reason is not granted sufficient time slices. But I am no expert on GDI questions. It does not look like a GDI renderer or compositor problem to me, because the GUI is not frozen, e.g. if I click on a scrollbar at the bottom of a chart window, with many seconds delay it will do the scroll, long before the extensive rendering process on the widgets is complete. The problem is somewhere else. I should have mentioned: The chartbook is charting MNQ, so it is definitely getting massive amounts of data. And again: The charts itself in all chart regions do update correctly without noticeable delay. It is just the other "parts" on the main window and child windows that show the massive rendering delays. |
| [2026-06-11 20:58:42] |
| User512353 - Posts: 159 |
|
one more observation: When there is low data traffic, such as now, a few minutes before CME GLOBEX close, the rendering may start slow, as described above, but somewhere in the middle of the lengthy rendering process, it may suddenly draw everything immediately. This does not happen in RTH, when huge data traffic is incoming. |
| [2026-06-16 21:38:42] |
| Sierra_Chart Engineering - Posts: 24317 |
|
We apologize for the delay. This is definitely not correct: I would conclude that there is a problem somewhere in the concurrent execution of the DTC client and the graphics renderer, where either something is repeatedly stalled waiting on some semaphore or something like that, or the rendering process for some reason is not granted sufficient time slices.
We can only conclude there is some system specific issue. And all of the information about performance issues is here: High CPU Usage | Inactive User Interface | Poor Performance | Long Time to Load Chart Data | Charts Reloading Often Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2026-06-16 22:41:28] |
| User512353 - Posts: 159 |
|
From the user perspective, there is no difference between a SC main instance and a sub-instance, other than the DTC client. There may be other differences under the hood. But only you know about these. Anyway, since the problem only shows in a sub-instance and not in the main instance, the best chance to identify the root cause of the problem is to start with those places in the code where main- and sub-instance are handled differently. That of course is something only you can do. |
| [2026-06-17 14:28:11] |
| Sierra_Chart Engineering - Posts: 24317 |
|
No there are no differences. 100% identical: There may be other differences under the hood. But only you know about these.
The only operational difference, is that the streaming market data, will come from the main instance but that does not change anything with performance. Nothing at all. Historical data will still come directly from the Sierra Chart servers. There is nothing we are going to look at. There is absolutely nothing wrong on the Sierra Chart side or anything that we can do to help with this. Other than the link we gave for things that can have a performance impact. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2026-06-17 14:29:06
|
To post a message in this thread, you need to log in with your Sierra Chart account: