Login Page - Create Account

Support Board


Date/Time: Thu, 13 Aug 2020 05:34:38 +0000



[Sticky] - Notice: Study Exceptions in New Versions and Code Efficiency

[2020-05-05 04:48:31]
Sierra Chart Engineering - Posts: 88573 | Ending Date: 2021-04-05
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:
https://www.sierrachart.com/index.php?page=doc/SoftwareDownload.php#FastUpdate


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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-05-22 16:31:21
[2020-05-08 20:40:25]
User818063 - Posts: 3 | Ending Date: 2020-09-14
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]
Sierra Chart Engineering - Posts: 88573 | Ending Date: 2021-04-05
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-05-22 04:08:51
[2020-05-10 22:39:35]
Sierra Chart Engineering - Posts: 88573 | Ending Date: 2021-04-05
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-05-10 22:41:42
[2020-05-13 23:11:52]
User972768 - Posts: 159 | Ending Date: 2020-01-05 [Expired]
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 https://www.sierrachart.com/index.php?page=doc/ACSIL_Members_Functions.html#scGetPersistentInt

Thanks
Date Time Of Last Edit: 2020-05-13 23:41:16
[2020-05-13 23:42:40]
Sierra Chart Engineering - Posts: 88573 | Ending Date: 2021-04-05
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-05-14 00:20:41
[2020-05-21 18:43:00]
golding - Posts: 10 | Ending Date: 2020-08-28
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]
Sierra Chart Engineering - Posts: 88573 | Ending Date: 2021-04-05
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-05-22 04:08:23
[2020-06-17 09:45:39]
elji00 - Posts: 37 | Ending Date: 2020-11-30
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]
Sierra Chart Engineering - Posts: 88573 | Ending Date: 2021-04-05
No those are definitely different.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-06-17 18:07:15]
User972768 - Posts: 159 | Ending Date: 2020-01-05 [Expired]
@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 login with your Sierra Chart account:

Login

Login Page - Create Account