How To Release Memory

[NinjaTrader_Joydeep]

Hello coolmoss,
I suppose 6 MB is well within the permissible limit.

If you see the below video, NinjaTrader does reduces the memory usage too. The .Net Framework calls the garbage collector automatically as and when required.

http://screencast.com/t/DB0dCY815X01

[coolmoss]

So where does that leave me with the my strategy?

I have continued to block out various chunks of code, and thus far I was able to find that the simple code below is causing memory usage to increase at the rate of 5 to 10 meg of ram each re-enable. I found that F5 does the same thing with the mem (no surprise I suppose).

// Condition set for long NEW high of day
if (Close[0] > Close[1]
&& High[0] > MAX(High,Bars.BarsSinceSession)[1]
&& newOn == true)
{
DrawText("NEW" + CurrentBar, "NEW", 0, Low[0] - 2 * TickSize, Color.Black);
newHiLong = true;
orderLabel = "NEW";
entryOffset1 = newHiLoEntryOffset;
}

// Condition set for short NEW low of day
if (Close[0] < Close [1]
&& Low[0] < MIN(Low, Bars.BarsSinceSession)[1]
&& newOn == true)
{
DrawText("NEW" + CurrentBar, "NEW", 0, High[0] + 2 * TickSize, Color.Black);
newLoShort = true;
orderLabel = "NEW";
entryOffset1 = newHiLoEntryOffset;
}

I'm not sure if this is the only problem area, but for sure I can replicate this section of code causing significant leakage. Comment it out, repeatedly hit F5 and the memory stays very close to stable (similar to when I did it with SampleMA strategy). Uncomment block, and memory creeps up significantly, consistently, and obviously.

When I did the above test, all code to create or manage orders was also commented out, so it wasn't like this condition set was creating a bunch of orders or something. What you see above was ALL the code in OnBarUpdate() that was compiled.

[NinjaTrader_Joydeep]

Hello coolmoss,
To assist you further can you please send a toy NinjaScript code* (in a *.cs file) replicating the behavior to support[AT]ninjatrader[DOT]com

Please append Attn:Joydeep in the subject line of the email and give a reference of this thread in the body of the email.

I look forward to assisting you further.

*The "toy" just means something that is a stripped down version that isn't necessarily the whole logic. It makes things easier to rout out.

[coolmoss]

Will do Joydeep.

I did some research and it seems I can request .net garbage collection by this call:

System.GC.Collect();

What about placing that line in OnTermination() ?

[NinjaTrader_Joydeep]

Hello coolmoss,
We have not tested it at our end so cant say for sure if it will conflict with the internal logic of NinjaTrader. Its more of a C# query and beyond what we can officially support.

Also from MSDN

It is possible to force garbage collection by calling Collect, but most of the time, this should be avoided because it may create performance issues

http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx

I will however leave the thread open for some forum members who can shed more light on it.

[koganam]

So where does that leave me with the my strategy?

I have continued to block out various chunks of code, and thus far I was able to find that the simple code below is causing memory usage to increase at the rate of 5 to 10 meg of ram each re-enable. I found that F5 does the same thing with the mem (no surprise I suppose).

// Condition set for long NEW high of day
if (Close[0] > Close[1]
&& High[0] > MAX(High,Bars.BarsSinceSession)[1]
&& newOn == true)
{
DrawText("NEW" + CurrentBar, "NEW", 0, Low[0] - 2 * TickSize, Color.Black);
newHiLong = true;
orderLabel = "NEW";
entryOffset1 = newHiLoEntryOffset;
}

// Condition set for short NEW low of day
if (Close[0] < Close [1]
&& Low[0] < MIN(Low, Bars.BarsSinceSession)[1]
&& newOn == true)
{
DrawText("NEW" + CurrentBar, "NEW", 0, High[0] + 2 * TickSize, Color.Black);
newLoShort = true;
orderLabel = "NEW";
entryOffset1 = newHiLoEntryOffset;
}

I'm not sure if this is the only problem area, but for sure I can replicate this section of code causing significant leakage. Comment it out, repeatedly hit F5 and the memory stays very close to stable (similar to when I did it with SampleMA strategy). Uncomment block, and memory creeps up significantly, consistently, and obviously.

When I did the above test, all code to create or manage orders was also commented out, so it wasn't like this condition set was creating a bunch of orders or something. What you see above was ALL the code in OnBarUpdate() that was compiled.

Actually that code is creating what may be a pretty large number of new DrawObjects. (The multiple text objects that will be created). Disabling the strategy does not delete those objects.

I have not tested, so I am not absolutely sure, but you may be able to delete all those objects with a call to RemoveDrawObjects() in the OnTermination() event handler. While you are about that, I guess you might as well make an explicit call to the GarbageCollector as well.

[Ricam]

Why use MIN and MAX instead of Math.Min and Math.Max?

[SIZE="2"][FONT="Courier New"]For FirstBarOfSession:
 Lowest__Low=Low[0] and Highest_High = High[0];

For all bars after FirstBarOfSession: 
Lowest__Low   = Math.Min  ( Lowest__Low,   Low[0]);
Highest_High  = Math.Max  ( Highest_High,  High[0]);  It would be a very good idea to add code to remove some of the Draw objects so that you don't just keep adding more and more of them without limitation.

Another likely culprit is all those additional instances of the MAX and MIN classes that are being created. You can't use one time instantiation of those external classes in OnStartUp because the length parameter keeps changing. With each new bar the number of bars since SessionBegin increases by one and there is a new instance of MAX and of MIN that has to look at the values of ALL of those bars. If you are running COBC false, new instances will be created on every incoming TICK. 

This is very poor programming, with a glaring and obvious flaw: There is no need to keep going back to the beginning of the session and looking at all of the ever increasing number of bars to find the ones with the highest and lowest values. 

Instead you can just check each developing bar against its predecessor using Math.Min and Math.Max. These are operators that simply compare two values, not classes that need to examine every value in a dataset that keeps growing as the session progresses. The following "psuedo-code" shows how to do this.

[/SIZE]

This will greatly improve the computational performance of your strategy, which, however, will not be likely to improve its low odds of profitability.[/FONT]

[KhaosTrader]

A good practice I have found is to include RemoveDrawObjects() in OnStateChange event in the (State == State.Terminated) and also in the (State == State.Configure)

** This is for Ninja8