Support Board
Date/Time: Sat, 01 Feb 2025 19:03:27 +0000
Is there common memory region that shares tick information between charts
View Count: 586
| [2019-07-31 21:42:03] |
| User972768 - Posts: 166 |
|
Hello, If it is not a secret, would you be able to share internal data organization of the Sierra Chart? I wonder if there is a common area of memory that holds tick data and shares it between charts. For example, if I have 5 different charts in my chartbook showing ES in different forms (eg, 5-min, 4-tick Renko, Numbers Bars, etc), does each chart communicates with SCID files and has own copy of the file or they all share same source of data in the RAM? Sharing data is a bit more complicated to code but would save a lot of resources (multiple copies of the same data in the RAM; extra disk IO to read same updates, etc). Since you don't have any configuration files (eg, like Java applications like to pre-allocate RAM and have max limits, etc) I assume that everything in this area is done automatically. If this is not correct, could you provide hints at possible/recommended ways to configure my environment to improve Sierra's performance besides getting better hardware? Thanks and best regards |
| [2019-07-31 23:59:09] |
| |
|
does each chart communicates with SCID files and has own copy of the file Yes. Not sure the benefit of sharing the same source data since the bar time frames are generally going to be different between charts and other chart settings as well which affect bar building.In regards to disk I/O, the operating system has its own caching and with solid-state drives and being the data is read on another thread, we don't really see any practical benefit especially being that the data is read in large chunks at a time. It is not until Sierra Chart became 64-bit, did the potential for keeping the raw Intraday data in memory be possible and perhaps offer a benefit. But this is still treacherous with excessive memory use. Also the concept of disk I/O is an outdated one. With solid-state drives, especially ones directly connected to the PCI bus, and file caching, and efficient reads like Sierra Chart does, there really is not "disk I/O" that really goes on any longer. This is kind of a dated concept. During real-time chart updating, Sierra Chart does not read directly from the files, it reads from an internal cache so long as charts are updating more often than the default flush time of 3000 ms. Which we will make 5000 ms now that we are reviewing this again. 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, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2019-08-01 00:00:46
|
| [2019-08-01 04:32:29] |
| |
|
To improve performance of loading data for chart bars based on minutes, use a sub instance where you have set the Intraday Data Storage Time Unit to 1 minute. This is explained here: Changing Chart Bars Period: Improving Performance of Loading Chart Data Just adding an additional information. 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, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2019-08-01 04:32:47
|
To post a message in this thread, you need to log in with your Sierra Chart account: