Strategy Analyzer memory usage?

[bluelou]

After 3 or 4 backtests virtual memory on my PC is > 1.2 GB. At that point I have to close NT and restart to run additional backtests. This is a real hassle.

I've read some earlier posts on the subject and NT's response didn't seem very encouraging. Is it NT's view that this is a problem with .NET garbage collection and, therefore, not something NT plans to address?

Are you recommending that we figure out how to do our own garbage collection in a strategy? Do you have any recommendations as far as GC statements?

-Lou

[NinjaTrader_Dierk]

Could be several reasons:
a) backtested time interval is just too big -> make it smaller
b) your strategy custom code uses features outsider NinjaScript (like managing it's own collection etc) which migth eat up memory which is never realised -> verify with SampleMACrossOver strategy. If you don't experience the issue then it likely is your strategy. If you do, then you need to resort back to (a).
c) "custom garbage collection" likely makes no difference

[bluelou]

Dierk,
1) I'm only backtesting on 2 months worth of data.
2) I've tried doing garbage collection within the strategy. That only frees up memory while performing the backtest. It doesn't have any effect on the memory leak occuring with each new backtest.
3) I'm disappointed with NT's Strategy Analyzer but I'm not paying much I guess. Thx for your response.

-Lou

[NinjaTrader_Dierk]

2 months of 1 minute data definitely is no problem with the SampleMACrossOevr strategy. I can see you hitting the wall on backtesting anything sub-minute for 2 months.

[bluelou]

Dierk,
That's the case here. I'm using tick bars. Will this improve with NT7? A backtest using only 2 months of tick data isn't much to work with.

-Lou

[NinjaTrader_Dierk]

It will improve with NT7, but ticks bars will remain a challenge. Think about it: # of months to backtest * 20 trading days a month * 150,000 ticks per day e.g. on the ES * bytes used per tick = quite a lot.

[bluelou]

I guess. This didn't seem to be a problem with OpenQuant. I think their bar factory works differently. But that's your area of expertise, not mine. However, OQ product support is almost non-existent so NT is still the better choice.