Support Board
Date/Time: Thu, 23 Jan 2025 21:37:06 +0000
Memory Usage increases - what is normal?
View Count: 1402
| [2018-12-13 11:32:00] |
| SoS - Posts: 3 |
|
New to developing for SC here. Coming from Ninja and Multicharts, very impressed with how little memory and cpu power Sierra takes in comparison! Assuming a study does NOT have a memory leak, what is a normal increase in memory usage as time passes by? Let's say I open 5 charts of EURUSD, with a study of two subgraphs on each. If I leave SC running overnight, is it normal for memory usage to grow by double when I look at it again in the morning? My understanding is that the number of bars (and therefore subgraph's .Data[] array size) should not change that much because the "Number of days to load" is pretty much fixed. Is this correct? |
| [2018-12-13 11:38:17] |
| |
|
Make sure you are running the latest version. There could be a memory leak problem at the operating system level which we have worked around in the latest version which is now 1850. Doubling of memory seems too much but perhaps might make sense. It is hard to say. Even though the Days to Load is fixed, still over time the number of bars in the chart still grows. 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 |
| [2018-12-16 11:58:19] |
| SoS - Posts: 3 |
|
I give up. I've taken up two trial periods and still can't locate the problem. Tried with 1828 and 1850, memory usage is still ballooning, 3k at a time. I've scrapped all my classes and objects, and reverted to simple function calls instead, removed all usage of std:: libraries, delete[]'d even local arrays within void-returning functions. Still, RAM usage doubles after a couple of hours of running in realtime. I do use a lot of s_UseTool drawing objects (about 100). But all of them are individually .LineNumber'd, .Clear()'d before updating and what have you. Admittedly, a few of them use a .BeginDateTime member which the documentation says is much less efficiennt than .BeginIndex, but still, I don't see how that could make memory jump 3k with every new bar. Maybe the s_UseTool class isn't cleaning up after itself? Anway, I'm running out of time, so I guess I'll have to tell customers to restart Sierra every so many hours or when they feel things are getting sluggish. |
| [2018-12-16 19:12:20] |
| |
|
We think the problem is an operating system level issue and you probably are using sc.FreeDLL= 1. We have implemented a solution to this. We see you are running an older version of Sierra Chart. Update to the current version. This is not likely to be related to Chart Tool Drawings unless those are continuously increasing at a significant amount. A user should never have to restart Sierra Chart. See if the problem goes away when you close and reopen a Chartbook. But update Sierra Chart to the current version first. 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: 2018-12-16 19:13:45
|
| [2018-12-17 09:40:34] |
| SoS - Posts: 3 |
|
Problem solved. What did it was restricting the updating of drawings to once per bar only. (P.S. I still see no reason why continuous updating would increase memory usage, since they are the same drawings being updated an nothing new added. Any way, problem solved and thats what matters). |
To post a message in this thread, you need to log in with your Sierra Chart account: