Adding stop / target conditions slows optimization process down.

[UltraNIX]

Hey, I added like 10 conditions for Exit, be it Stop/Target/Trail variations. I want to add more, but I experience a reasonable slow down in Strategy Analyzer window, Optimization mode. It takes more than 5 minutes to run test of 2 results.

One obvious fix would be "remove those additional parameters and it would work fine again". That's too easy and too obvious. And not acceptable.

I want to improve the code of the strategy, so it would be both fast and efficient. One thing I implemented is using variables for MAX and MIN calculations.

[NinjaTrader_Jim]

Hello UltraNIX,

Thanks for your post.

To improve backtesting performance and memory utilization, it would be advised to write the strategy so it can be used with IsInstantiatedOnEachOptimizatonIteration = false. To use this property, the strategy must reset all of its class level variables in State.DataLoaded.

IsInstantiatedOnEachOptimizatonIteration documentation — http://ninjatrader.com/support/helpG...niteration.htm

State Management Best Practices (please see Resetting class level variables for Strategy Analyzer Optimization) - https://ninjatrader.com/support/help...urceManagement

As another tip to improve backtesting/optimization performance, we advise to avoid using Draw methods. You can protect your drawing code with a check for if (!IsInStrategyAnalyzer) to prevent having the draw methods used in the StrategyAnalyzer.

IsInStrategyAnalyzer - https://ninjatrader.com/support/help...egyanalyer.htm

We look forward to assisting.

[UltraNIX]

Am I reading it right, that I will be losing trade journal if I set IsInstantiatedOnEachOptimizatonIteration to FALSE?

I also tried to write a "shadow" strategy and include only one Stop/Target/Trail variation in hopes of faster testing and optimizing, but for one "heavyweight method" it didn't help. If I posted my calculation formulas here, maybe somebody could help and see if there's a "lighter workaround".

[NinjaTrader_Jim]

Hello UltraNIX,

Are you referring to the comment in the code snippet below?

// A custom trades dictionary is created when strategy is instantiated
// since we later set "IsInstantiatedOnEachOptimizationIteration" to true,
// we are guaranteed to start with a new object on each optimization run
private Dictionary<DateTime, string> myTrades = ne w Dictionary<DateTime, string>();

This reflects the private Dictionary added in the script. This class level variable will need to be cleared and recreated after State.DataLoaded so it is properly refreshed for the next test of the strategy.

If IsInstantiatedOnEachOptimizationIteration is set to true, you won't have to worry about this variable cleanup because a new instance of the strategy (and new properties) are created with each optimization iteration. However, this comes with a performance penalty, so it would be best to reset your class level variables in State.DataLoaded and set IsInstantiatedOnEachOptimizationIteration to false.

We look forward to assisting.

[hedgeplay]

Hi UltraNIX,

A very pragmatic working approach I recommend is to via the Task Manager or Performance Monitor optimization using smaller and larger numbers of optimization parameters.

1) Observe enough runs to identify the total number of executions per Optimization your PC can handle before it begins crawl, swapping memory, etc. Maybe one machine 5000 executions maybe another 9000 executions.

2) Note what ever that number is for your machine. Your machine's "Happy Number'" Lol.

3) Take a few seconds to plan ahead,

3a). "bifurcate" your experiments so the number of executions never exceed this Happy Number.
3b). Plan experiments thoughtfully so the results of one narrow the remaining questions for the next

Hedge

[UltraNIX]

Hi UltraNIX,

A very pragmatic working approach I recommend is to via the Task Manager or Performance Monitor optimization using smaller and larger numbers of optimization parameters.

1) Observe enough runs to identify the total number of executions per Optimization your PC can handle before it begins crawl, swapping memory, etc. Maybe one machine 5000 executions maybe another 9000 executions.

2) Note what ever that number is for your machine. Your machine's "Happy Number'" Lol.

3) Take a few seconds to plan ahead,

3a). "bifurcate" your experiments so the number of executions never exceed this Happy Number.
3b). Plan experiments thoughtfully so the results of one narrow the remaining questions for the next

Hedge

Thanks, that's a really good answer. From what I've experienced, some "heavier" calculations begin to crawl even in 20 executions, while other 'lighter' ones can run in thousands. But yes, I start with larger increments to narrow down the range where 'the magic happens' and then decrease increments to fine tune.

[UltraNIX]

Hello UltraNIX,

Are you referring to the comment in the code snippet below?

// A custom trades dictionary is created when strategy is instantiated
// since we later set "IsInstantiatedOnEachOptimizationIteration" to true,
// we are guaranteed to start with a new object on each optimization run
private Dictionary<DateTime, string> myTrades = ne w Dictionary<DateTime, string>();

This reflects the private Dictionary added in the script. This class level variable will need to be cleared and recreated after State.DataLoaded so it is properly refreshed for the next test of the strategy.

If IsInstantiatedOnEachOptimizationIteration is set to true, you won't have to worry about this variable cleanup because a new instance of the strategy (and new properties) are created with each optimization iteration. However, this comes with a performance penalty, so it would be best to reset your class level variables in State.DataLoaded and set IsInstantiatedOnEachOptimizationIteration to false.

We look forward to assisting.

I will try to play around with this. I am leaving today for a small trip, so when I get back and have additional questions, I will bump this thread up.