6.5.08 easy to crash on many variables passed to optimizer

[scriabinop23]

I'm doing extensive backtesting in 6.508 with a strategy I have that has 7 customizable variables that I'm backtesting against 5 yrs of data (on 5 minute bars). It uses extensive onorderupdate() logic as well as a custom indicator that I assume adds a whole few additional seperate data arrays to the memory requirements. [i noticed upon using this indicator that my backtesting became quite a bit slower versus using a bar by bar version of the indicator that stored no arrays, merely evaluated some price variables via some logic that worked on existing indicators]

Anyway, its very hit or miss - I can pretty easily crash 6.508 of ninjatrader by a few rounds of optimizing the strategy. Often if I do a large optimization, I'm better off if I restart the app from scratch before doing it.

I have 3gigs on this machine; so there is no memory issue. The application size in memory can get from 200mb-1gig pretty quickly.

Ideas? I'm running the latest .NET framework. Will the strategy analyzer forever be laden with innefficiencies by using so much of the microsoft framework, and inherently potentially 'wasteful' code design by amateur programmers [who let far too many and too large data arrays exist upon backtesting] ??

[NinjaTrader_Dierk]

What kind of error message do you get?

[scriabinop23]

What kind of error message do you get?

ninjascript has detected a problem and needs to shut down... Its about a paragraph long. I need to kill the app in the task manager to continue.

[Pete S]

Do you have any object or array variables in your strategy class?

[scriabinop23]

Do you have any object or array variables in your strategy class?

No array variables referred to besides references to indicators ( a la EMA() or derivatives of those); and yes, plenty of object variables. Ie I am within the strategy as well as order logic referring to performance variables, bars since exit/entry, etc.

[Pete S]

I mean specifically in the variables section of your class definition. If you do, you'll want to do this:

~MyStrategyClass()
{
myIndicator1 = null;
myArray1 = null;
}

I started doing this after reading an article on .NET memory management and it has made a huge improvement, to the point where it's rare for me to see out of memory exceptions these days.

If you are just using them in your OnBarUpdate this wouldn't apply.

[scriabinop23]

I mean specifically in the variables section of your class definition. If you do, you'll want to do this:

~MyStrategyClass()
{
myIndicator1 = null;
myArray1 = null;
}

I started doing this after reading an article on .NET memory management and it has made a huge improvement, to the point where it's rare for me to see out of memory exceptions these days.

If you are just using them in your OnBarUpdate this wouldn't apply.

i'm just using onbarupdate. And the only object variables i've arbitrarily created are for OnOrderUpdate (the private iOrder order = null; declarations that care of that).

how long periods do you generally backtest against, though? perhaps the size of my test sets is whats creating the problem (5 yrs of minute data, heh).

[NinjaTrader_Dierk]

I would want to take a look to get a better picture. I would suspect it's just a limitation for now you're running into, but who knows...

Would be great if you could mail me:
- strategy to back test
- screenshot of optimizing parameters
- traces and logs
- DB you're running the optimizer on

At best you could upload all info to our servers by Help->Mail to support, subject "for Dierk".

Thanks in advance

[scriabinop23]

I would want to take a look to get a better picture. I would suspect it's just a limitation for now you're running into, but who knows...

Would be great if you could mail me:
- strategy to back test
- screenshot of optimizing parameters
- traces and logs
- DB you're running the optimizer on

At best you could upload all info to our servers by Help->Mail to support, subject "for Dierk".

Thanks in advance

guess what... i experimented with this thing. my strategy had plenty of debug output (including traceorders) going to the output screen. I disabled all the debugging (actually I added a little boolean logic to let me quickly turn on or off all of my internal debugging more specifically), and it appears the backtest optimization is much more stable. I haven't been able to get it to crash on even long spans of data. I haven't compared side by side results with the debug set on, but debug window off, yet.

Next two things we need: Monte carlo optimizer and multiprocessor utilization.

Thanks for the response. (and Pete: I'm using your optimization timer now - it works excellently. I was able to find 'heavier' parts of my code and reduce them).

[NinjaTrader_Dierk]

Thanks for feedback. Could you please send me logs and traces regardless. I would want to see what's going on exactly?

Thanks