Changing interval settings - Speed issue

[Harry]

I just made a test with one of my standard chart templates. The template includes several indicators that require a few calculations. I used this template on ES 06-09 with a lookback period of 90 days. During the test I was not connected to any data supplier.

These were the waiting times (each test conducted at least 3 times, fully reproducible)

Opening a chart with 5-min-interval: 5 seconds
Closing the 5-min-chart: 3 seconds
Opening a chart with 2-min-interval: 8 seconds
Closing the 2-min-chart: 14 seconds
Opening a chart with 1-min-interval: 17 seconds
Closing the 1-min-chart: 170 seconds (yes, close to 3 minutes!)
Changing intervals from 1 to 2 minutes: 178 seconds
Changing intervals from 2 to 1 minute: 30 seconds

So, if I change my interval settings of the 1 minute chart to 2 minutes, I will have to wait for about 3 minutes. If I just open an identical new 2-min-chart using the chart template, it only takes 8 seconds.

Can you explain this?

Why does NT take 170 seconds to close a chart that is no longer needed? And worse, in connected mode (this was outside the test), NT cannot be used during these 3 minutes (temporary freeze due to high processor load).

[NinjaTrader_Josh]

Harry,

Please provide this template. Thank you.

[Harry]

Josh,

thanks for your answer.

After testing I found that just one very simple indicator caused the problem. The indicator identifies Narrow Range (NR7) and Inside Bars. Within the indicator I could track the problem down to the use of the DrawDiamond() method:

margin = 0.25*ATR(11)[0];
if (myNR7 && !myIB)
DrawDiamond("NR7"+Convert.ToString(CurrentBar),true, 0, High[0]+ margin, Color.Cyan);

Anything wrong with this?

Indicator attached (C#-file directly zipped, as NT export utility does not work for this inidcator)

Harry,

Please provide this template. Thank you.

[NinjaTrader_Josh]

You do not need to do any Convert.ToString() business. Just do "IB" + CurrentBar for the string name. Doubt that will fix/break anything though.

Likely you want to pay attention to this margin variable. This value does not seem to be adjusted for tick size and depending on the instruments you actually run on this may or may not be a value way outside the range of High[0] and thus cause charting issues.

[Harry]

Hello Josh,

(1) With the ATR approach the drawing distance of the diamonds is automatically adjusted to the time interval chosen for the chart, which cannot be achieved by using TickSize. Just to check, I replaced margin with TickSize, and it did not have any impact on the speed issue.

(2)The Convert.ToString() business is just to tag the diamonds. Otherwise I will only find one single NR7 bar on my chart. If I want more than one diamond, I need to keep the tags.

What causes this untimely behaviour? I am running complicated Fibonacci and Pivot indicators, and they are all reasonably fast. Only this indicator shows problems - and only when it is removed(!) -, and these problems are likely being created by the DrawDiamond() method!

Can you explain it?




You do not need to do any Convert.ToString() business. Just do "IB" + CurrentBar for the string name. Doubt that will fix/break anything though.

Likely you want to pay attention to this margin variable. This value does not seem to be adjusted for tick size and depending on the instruments you actually run on this may or may not be a value way outside the range of High[0] and thus cause charting issues.

[NinjaTrader_Josh]

Harry,

You will need to debug it. You need to keep it simple till you isolate out which area has issues. Swap out the ATR, use a very simple double value, swap out the convert. Swap out all parts for simple replacements.

[Harry]

I also replaced the "+Convert.ToString(CurrentBar)" by "+CurrentBar" as you suggested. No improvement - still takes 3 minutes to delete the indicator.

[Harry]

Hi Josh,

I have debugged it. I have taken margin and ATR out and replaced it by TickSize. Actually the indicator is very simple. There is nothing left to debug.

The only remainder is the DrawDiamond()method. So the problem must lay there!

If I take DrawDiamond() out, the problem disappears.

[NinjaTrader_Josh]

Harry,

If your indicator is drawing a million diamonds for sure it will slow down the chart. Please slowly layer out code complexity and limit the number of actually drawn objects.

I assure you DrawDiamond() works. You need to layer out complex parameters you are passing into DrawDiamond() then layer out the frequency of DrawDiamond() calls.

[Harry]

Hi Josh,

The minimum inidicator that unconditionally attaches one diamond to every bar, see following code

protectedoverridevoid OnBarUpdate()
{
DrawDiamond("A"+CurrentBar,true, 0, High[0]+ TickSize, Color.Fuchsia);
}

already kills NT. There is something wrong, if NT can print bars and complicated indicators but not diamonds. There is no reason that drawing a diamond should take more time than drawing a bar!

[NinjaTrader_Josh]

Harry,

As stated, if you are drawing diamonds on every single bar for sure it will be slow.

[Harry]

There was a little bit of hope on my side that DrawDiamond() could be improved....

In particular it would help, if it could be removed faster than in 3 minutes.

[NinjaTrader_Josh]

Harry,

If you run on 90 days worth of charts that is a lot of bars. You are even running multiple charts. Your indicator is adding an object on every single one of these bars. It is not a mystery why it performs slow.

A. Decrease your chart data significantly
B. Decrease the amount of draw objects you add significantly

[Harry]

Josh,

if I take the one line indicator below and put it on a 1-min-chart with a lookback period of 60 days, it will show up within a second. Removing the indicator takes 20 seconds. So it takes 20 times longer to remove the diamonds than to draw them.

I therefore think that the DrawDiamond() method is flawed. I am just communicating this because I wish to contribute to improving NinjaTrader. For my needs I can get around the problem by reducing the lookback period just for this indicator.

[NinjaTrader_Josh]

Harry,

As discussed already, do not add so many draw objects. Especially not on every single bar. You are just asking for trouble doing so many objects and as you have experienced you ran into performance issues when you did it.

[Harry]

My question was never considered or answered.

[NinjaTrader_Josh]

Harry,

As discussed in this thread already on several posts. You are clearly running into performance limitations as you try to add draw objects on every single bar, not on one chart, but on multiple charts. Furthermore, these charts contain extensive chart data to further compound the performance hit. We have already stated that this will undoubtedly result in the performance behavior you have experienced. We are always optimizing performance throughout the software, but the way to proceed as of currently is to make the recommended adjustments.

[Harry]

Josh,

There are no considerable performance limitations when adding the indicator.

Performance limitations only occur when removing the objects.

Why?

[NinjaTrader_Josh]

Harry,

Unfortunately there is nothing further I can provide you with. Please proceed as recommended.