Hi Guys:

I am having a weird timing/resource scheduling/sharing issue from the execution of a strategy that uses 2 NNindicators and ends up throwing an exception when a few copies of the strategy are run in parallel. When one strategy runs by itself, no problem it runs smoothly.

The inputs to the Neural Network are a series of indicators that are somewhat computationally intensive and this complexity seems to trigger the resource sharing issue, but it seems to be internal to the NNIndicator code. So I am left with the challenge of making my code more efficient to reduce the computational burden to hopefully avoid the scheduling problem.

I realized there are a few things I can do to make the code more efficient. Both NNindicators use the exact same input series, and I am also creating those indicators in the strategy (for graphing and trade entry/exit decisions). But this means that the indicators and it's derivatives are being calculated 3 times:
1) The strategy instantiates them for graphing and trade loop decisions.
2) The NNIndicator 1 instantiates them in its input script again
3) The NNindicator 2 instantiates them in its input script yet again

Is there a way that I can instantiate the indicators once in the strategy and instead of creating them again in each inside each NNIndicator, just refer to the ones that the strategy instantiated (thereby avoiding the 2 additional instantiations?

Another way would be to pass the indicators as a parameter to the NNINdicator method, but I don't think there's an overload that accepts additional parameters.

Hi Jorge,

QUOTE:
I am having a weird timing/resource scheduling/sharing issue from the execution of a strategy that uses 2 NNindicators and ends up throwing an exception when a few copies of the strategy are run in parallel. When one strategy runs by itself, no problem it runs smoothly.

I cannot but repeat my answer from 11/11/2017 to your ticket. This looks like a thread safety issue in the NNIndicator or in your own code. Please avoid running your NL-based Strategy in Streaming mode and/or in parallel.

QUOTE:
Another way would be to pass the indicators as a parameter to the NNINdicator method, but I don't think there's an overload that accepts additional parameters.

No, there isn't.

QUOTE:
Both NNindicators use the exact same input series,

Which means that the NNIndicator takes the series from Bars.Cache and won't re-calculate it.

QUOTE:
Which means that the NNIndicator takes the series from Bars.Cache and won't re-calculate it.

Great.. that's a great cue...my indicators are custom indicators and I had not formalized them into the standard compiled indicators that use the Bars.Cache mechanism. So I guess I'll work into put them into formalize them and put them into the Cache and see if that brings any performance improvements.

It's not strictly required (although desirable) to build an indicator library but as you just correctly pointed out, implementing caching is a clue. An example can be seen in the Fidelity API PDF, page 3:

http://personal.fidelity.com/products/trading/Trading_Platforms_Tools/pdf/Creating-an-Indicator-Library-in-Wealth.pdf