Indicator caching and Singleton

[DaveE]

I found that if an Indicator makes use of a Singleton (say defined in a library class) then it is no longer cached on chart.
I had thought that NT was supposed to cache an indicators if different instances have the same parameter values.
To keep things simple I created a simple indicator with no input parameters, one plot intended for main chart, another intended for a different panel.
If the indicator uses Random then I want the indicator executed only once on the dataseries, so the same random number is used for both instances of the indicator.
If I create an instance of Random at the indicator level, then the caching works fine.
However its supposed to be best practice to access Random via some kind of (per thread) Singleton, because Random is not thread safe.
If I change the indicator code to use an instance of Random from a 'per thread singleton' like the code here put into a library class, then the indicator is no longer cached. So the indicator gets executed for each instance on the chart, resulting in different random numbers being used in different panels, for the same bar.

Has anyone found a work-around for this problem?

I expect that the NT engine already has some kind of singleton for Random, perhaps this could be made available to users in NT8? And perhaps NT engine programmers could ensure that using it did not prevent NT from caching.

[NinjaTrader_PatrickH]

Hello DaveE,

Thank you for your post.

I will be following up here shortly on this matter.

[NinjaTrader_PatrickH]

Hello DaveE,

Thank you for your patience.

Can you provide the example in it's .cs file format attached to your response of Singleton that was not working as expected?

[DaveE]

Have done a few more tests, and I have come to the conclusion that NT7 charts do not do any indicator caching.

I had assumed that if user puts the same indicator with the same indicator input values onto a chart multiple times (say to show different plots on different panels) then the Chart (for efficiency) would do something like this:
Create one instance of the indicator (for each unique set of input values), cache the resulting plots, display the plots on the requested panels from the single cached instance.

But how it actually seems to work seems very inefficient both for memory and CPU:
Create a separate instance of indicator each time specified in chart (regardless of whether input values are the same or not).
This means that every time the user has repeated the same indicator on the chart with the same input values, the NT chart will: call Initialize() for each one, call OnStartup() for each one (but user might be creating some expensive object here), call OnBarUpdate() for each one (for each new bar).

What happens if the user does something like this in OnStartup()

rnd = new Random();

Is that NT charts will probably instantiate both instances of the indicator (say one for panel 1, another for panel2) in the same timeslice so both get the same seed, so both instances of rnd will generate the same sequence of random numbers, giving the appearance that NT chart has cached the indicator.
Whereas if you code the indicator to use a singleton to access a common instance of Random, then each indicator will (probably) get a different random number simply because NT chart is making a separate call to OnBarUpdate for each bar for each duplicate indicator.

I'm not expecting anything to change for NT7. But perhaps you could confirm that my understanding is correct for NT7 charts.

Since its common for users to write indicators with plots intended for different panels, I would like to request that NT8 Charts should either try to cache duplicated indicators by default, or perhaps this should be a user selected option.
It might need to be a user selected option in case some users are relying on side effects produced by duplicated indicators being executed for each duplicate, for each bar as in NT7.

[NinjaTrader_PatrickH]

Hello DaveE,

Thank you for your response.

From my understanding you are correct, I will forward this and your suggestion to our development team.

[NinjaTrader_PatrickH]

Hello DaveE,

Thank you for your patience.

The indicator's are actually cached, but no use of singleton. You can view the caching logic in the NinjaScript Wrappers when editing an indicator. You can find additional information on this matter at the following link: http://www.ninjatrader.com/support/f...ad.php?t=34719

Please let me know if you have any questions.

[Ricam]

Caching is the WRONG WAY to deal with this problem.

That's why it is so inefficient to use inline calls to external classes. The solution is not to rely on the feature of caching the indicators, which, when it works at all, tends to become very sluggish as the number of indicators in the cache grows and grows..

The solution, that you can do right now, is to create, during the Configure state, instances of your external classes, and then refer to them in the event driven code. Examples abound in the system indicators, such as TMA. Unfortunately, not all of the Ninjatraders seem to be well versed in this technique, which should be listed prominently as a best practice, whereas last time I looked it was not even mentioned.

RWT-004
2009-08-18
In all of the coding tutorials and examples I've seen, Ninjatrader indicators are used
in-line. So, if you want to know when the SMA is going up, you'd check:
SMA(Close, 5)[0] > SMA(Close, 5)[1]
I find this practice repulsive for two reasons: redundancy and inefficiency. This paper
chronicles the path I took to finding a better way. If you just want to know what the
better way is, skip to the 'Solution' section at the end.

This has been mentioned elsewhere.. how soon we forget. Recommend that you download the link and read it carefully.

http://ninjatrader.com/support/forum/attachment.php?attachmentid=24547&d=1358948048

Otherwise you are repeatedly creating new objects to be used a single time then never used again, one of the best possible ways to sabotage the performance of your code. As an added bonus, the inline function calls are a mess of repetitive, duplicative gibberish.