Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Fri, 26 Apr 2024 00:31:24 +0000
Notice: Study Exceptions in New Versions and Code Efficiency
View Count: 4639
| [2020-05-05 04:48:31] |
| |
|
We have had several reports of users encountering exceptions with custom studies in newer versions of Sierra Chart. The old persistent variable structure (sc.PersistVars) has been removed and has been considered out of date 5 years now. Custom studies that use this will encounter a null pointer exception. This is the reason for the problem. Also custom studies that were recompiled in the last two years could not even use that object because it was renamed and became therefore inaccessible. This should not lead to any instability but does prevent the study from functioning and does generate a lot of log messages. In the case where these studies are part of User Contributed studies, run the Sierra Chart installer just by performing a Fast Update: Software Download: Fast Update And on the installer window enable "Install Optional Components". After the installation is complete and you run Sierra Chart, you will no longer have the issue. In other cases, old code needs to be updated as follows. Old code: int& VariableName = sc.PersistVars->i1;
New code: //The parameter 1 needs to be a unique number for each // persistent variable. But can be the same among different // data types. Always use low integer values to support // the new fast upcoming persistent variable functions. int& VariableName = sc.GetPersistentIntFast(1); Code Efficiency: Onto the subject of code efficiency. Study functions should use manual looping for the greatest efficiency. Automatic looping is less efficient, but not generally by much, and depending upon what the study function is doing, it could be very inefficient as compared to manual looping. Studies which use more than a few persistent variables really do need to use manual looping. Manual looping really is the absolute best. Automatic looping was provided for convenience/simplicity a long time ago. Otherwise, it serves no other purpose. When accessing a persistent variable when using sc.GetPersistent* functions, these must be called as minimally as possible. Not frequently. We are going to create new high-performance versions of these, as soon as possible. If you are accessing a small number of persistent variables like less than 10, there really is not much performance impact but more than that, progressively there would be more of a performance impact. However, in reality, the performance impact is likely to be when you have thousands of persistent variables. Otherwise, the performance impact simply would not be noticeable unless you are monitoring study performance down to the microsecond level. 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: 2020-05-22 16:31:21
|
| [2020-05-08 20:40:25] |
| User818063 - Posts: 15 |
|
I believe the real function is GetPersistentInt, not sc.GetPersistentInteger so code that compiles will be : int& VariableName = sc.GetPersistentInt(1); |
| [2020-05-09 12:38:31] |
| |
|
Yes, this is correct. These are the new fast persistent variable functions: int& sc.GetPersistentIntFast(int32_t Index); float& sc.GetPersistentFloatFast(int32_t Index); double& sc.GetPersistentDoubleFast(int32_t Index); SCDateTime& sc.GetPersistentSCDateTimeFast(int32_t Index); Index can be from 0 to 999. Always start with 0 or 1 and go up. 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: 2020-05-22 04:08:51
|
| [2020-05-10 22:39:35] |
| |
|
We had a question by email as to why the existing ACSIL persistent functions were not optimized and these new ones were created. And whether these new ones should always be used now. Yes use these fast functions from now on in most cases. The other functions are still useful for pointers and strings and when accessing persistent variables across charts and studies. And when you need to use a key value that does not fit within the index range of 0 to 10000. The older ACSIL persistent functions cannot be optimized because they support a random key value which can be in the range from zero to UINT_MAX. Whereas the fast ones specifically are using an index which needs to start at 0 and go up. Although perfectly fine to start at 1 and fine to skip indexes but you should not. The old ones use a STL map, the new ones use a STL vector. 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: 2020-05-10 22:41:42
|
| [2020-05-13 23:11:52] |
| User972768 - Posts: 166 |
|
Hello Support, While we're on the topic of Persistent variables. Just wanted to confirm that referring to persistent variable int #1 is specific to each copy of the study. For example, following code int& VariableName = sc.GetPersistentIntFast(1); will return references to two different memory addresses in two different copies of the study even on the same chart. Is it correct? And to expand this question. If I have multiple studies in my DLL referring to persistent int variable as in code above, they all should refer to different memory regions, right? PS Please do not forget to add information about new "Fast" methods at sc.GetPersistentInt() Thanks Date Time Of Last Edit: 2020-05-13 23:41:16
|
| [2020-05-13 23:42:40] |
| |
|
Just wanted to confirm that referring to persistent variable int #1 is specific to each copy of the study. Yes and the documentation does explain this.
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: 2020-05-14 00:20:41
|
| [2020-05-21 18:43:00] |
| golding - Posts: 15 |
|
Any plans to allow accessing FastPersistent variables across charts and studies? I'd prefer to switch to FastPersistent* without having to distinguish between variables accessed by different studies/charts... |
| [2020-05-22 04:06:44] |
| |
|
No not now in regards to post #7. A safety problem was discovered involving these functions: int& sc.GetPersistentIntFast(int32_t Index);
float& sc.GetPersistentFloatFast(int32_t Index); double& sc.GetPersistentDoubleFast(int32_t Index); SCDateTime& sc.GetPersistentSCDateTimeFast(int32_t Index); There was not consideration to how when the internal vector is increased in size, that the memory addresses can change which means that as references are being made to the returned values, prior references made during the same call to the custom study function could change meaning the study function could be writing to an address which is no longer valid. And in that case the reference address would change on the next call into the study function. This is now resolved in version 2109. Effective with that version the valid range for the Index parameter is now 0 to 999. 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: 2020-05-22 04:08:23
|
| [2020-06-17 09:45:39] |
| JM-JO - Posts: 38 |
|
Hello Support, A question relative to the new sc.GetPersistent*Fast variables : are the two following references referring to the same integer ? int& VariableName = sc.GetPersistentInt(1);
int& VariableNameFast = sc.GetPersistentIntFast(1);
It was not clarified in documentation. |
| [2020-06-17 11:11:03] |
| |
|
No those are definitely different.
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 |
| [2020-06-17 18:07:15] |
| User972768 - Posts: 166 |
|
@elji00 According to post #4 of this thread there are 2 different objects behind "old" and "fast" ways. One is STL map (for "old"), and another one is STL vector (for "fast"). As these are totally different memory structures, accessing first element from your example returns int values from different memory regions.
|
To post a message in this thread, you need to log in with your Sierra Chart account: