Support Board
Date/Time: Wed, 14 May 2025 08:31:18 +0000
Post From: SC burns CPU resources on continually accessing data files even with markets closed
| [2016-04-02 00:32:10] |
| i960 - Posts: 360 |
|
With all markets totally closed and no incoming market data at all, SC still burns CPU doing the following: 1. Needlessly tries to create files for already existing intraday/daily data files (which of course error because they already exist), but this may be a non-issue in itself and just part of the access function. 2. Needlessly reads 1 record of intraday data from the end of all open intraday/daily data files on a frequent and continual rate across every single chart open across all chartbooks. 3. Can be easily reproduced by opening a chartbook and then monitoring it with procmon (sysinternals). In some cases (namely aftermarket equities still being open), one can even *close* their chartbooks entirely and *still* see SC accessing and updating the data files. 4. It does this regardless of being connected or disconnected to one's trading service. The only solution is completely closing out the chartbooks. In the case of AH equities, simply disconnecting suffices. This isn't just 1% CPU either; with a large amount of chartbooks/charts open one can see 8-10%+ CPU basically doing nothing useful whatsoever. While that may not seem like a big deal because one can always just close their platform when not trading, it's still going to be doing this behavior anytime it's open and in use (including slow/closed markets, etc), which includes normal trading sessions. I suspect this behavior is entirely being driven by this functionality: http://www.sierrachart.com/index.php?page=doc/doc_IntradayDataFileFormat.html#FeedSierraChartData and/or something related to multi-instances. If the *vast* majority of people are not writing scid or dly files externally outside of SierraChart (which is most likely the case), there needs to be a way of either disabling this across the board, or making it a per chart setting. Additionally, if there's some kind of multi-instance need for doing this, then there should simply be a better way of handling it, because having processes basically continuously tail 40 bytes from the end of every single chart is far from efficient. If you're going to do the equivalent of stat()ing every single chart that's open - why not simply just check the filesize and if it hasn't varied then don't bother reading 40 bytes of data that hasn't even changed. I've captured both a screen capture of the procmon log and even made a video showing this happening (+me disconnecting and the same thing continuing). Video: https://www.youtube.com/watch?v=bHwm2ZmsVZc ** Remember now, the global futures markets are closed, there is no incoming market data driving the charts whatsoever. |
 Screen Shot 2016-04-01 at 1702.17.png / V - Attached On 2016-04-02 00:05:58 UTC - Size: 1.27 MB - 297 views |