Login Page - Create Account

Support Board

Date/Time: Fri, 25 Sep 2020 04:25:59 +0000

Post From: Notice: Study Exceptions in New Versions and Code Efficiency

[2020-05-05 04:48:31]
Sierra Chart Engineering - Posts: 89884 | 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:

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:

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