Does OnBarUpdate block other instances of itself?

[anachronist]

Generally I try to search these forums before asking a question, but in this case I don't know what to search for.

Suppose CalculateOnBarClose=false. If my OnBarUpdate() method includes code that takes longer to execute than the interval between ticks, what happens? Does a new OnBarUpdate() event fire off each time a tick comes in, causing a delayed pile-up of calls to this method (or worse, multiple concurrent executions of the same OnBarUpdate() method)? Or does each call of OnBarUpdate() block further tick events from calling it until it completes?

The desired behavior for me would be for OnBarUpdate() to block further calls to it until it's done, to ensure that it can execute completely from beginning to end. If ticks must be skipped to facilitate OnBarUpdate() finishing execution, that's fine. I don't want a delay to accumulate because the code is slow.

-Alex

[NinjaTrader_Joydeep]

Hello anachronist,
Every bit of code in OnBarUpdate event is calculated before a new tick is processed. Thats why, if your code is very intensive NT can freeze. As such it is advisable to optimize your code.

For example if your code uses only price then dont process the code if the current tick is equal to the previous tick as the outcome will be same. a simple code would look like:

in variable

double price = 0;

in the begining of OnBarUpdate do a quick check

if (price == Close[0])
{
  
  return;
}
price = Close[0];

Please let me know if I can be of any further help.

Regards,
Joydeep.

[anachronist]

Thank you Joydeep. From your answer I assume that ticks are not skipped if processing takes too long; rather, calls to OnBarUpdate() will be queued, and the queue will build up if each execution of OnBarUpdate() takes longer than the interval between ticks.

I will implement the solution you suggest, although I think the test should be this instead:

if (!FirstTickOfBar && price == Close[0])
   return;

That way the code will still execute on the first tick of the bar even if it happens to be the same as the last tick of the previous bar.

-A

[NinjaTrader_Joydeep]

Hello anachronist,
Yes right. Ticks are not skipped. Also yes, FirstTickOfBar is a good check I forgot to mention.

Please let me know if I can be of any further help.

Regards,
Joydeep.

[anachronist]

Following up on optimized code....

Skipping execution when the current tick price equals the last tick price does help.

However, it helps even more to have more efficient indicators that calculate values on the fly without using loops.

I have created highly optimized drop-in replacements for LinReg, LinRegIntercept, LinRegSlope, SMA, StdDev, and WMA. They give identical results to their default NinjaTrader counterparts, but they use absolutely no loops. This means, for example, if you are calculating a 21-bar StdDev, it would executes about 20 times faster than the default StdDev NinjaScript.

They work equally well when CalculateOnBarClose is true or false, and they don't need to allocate any DataSeries memory. These required some thought to work out but turned out fairly simple and elegant, using loop-less running sums.

Would NinjaTrader consider substituting their default indicators with these faster ones I made? I think everyone would benefit from having these be the defaults rather than maintaining a separate library of "fast" versions. They would also automatically speed up other built-in indicators like HMA (which uses WMA). I'm happy to give them to you guys without royalties.

Here's an example for a super-fast standard deviation:

	// variables
	private int period = 14;
	private double sy20, sy21, sy0, sy1, N, avg;

	protected override void OnStartUp() {
		sy0 = sy20 = 0.0;
	}

	protected override void OnBarUpdate() {
		if (FirstTickOfBar) { // save prior sum(y^2) and sum(y) values
			sy21 = sy20;
			sy1 = sy0;
		}
		sy20 = sy21 + Input[0] * Input[0];
		sy0 = sy1 + Input[0];
		if (CurrentBar < period) // N == period when no longer true
			N = CurrentBar+1;
		else {
			sy20 -= Input[period]*Input[period];
			sy0 -= Input[period];
		}
		avg = sy0 / N; // this can also be publicly exposed for external use
		Value.Set(Math.Sqrt(Math.Max(0.0, sy20/N - avg*avg)));
 	}

-Alex

[NinjaTrader_Joydeep]

Hello,
Thanks for your post.

I have forwarded the issue with development, who reported back, that they are already looking into across the board optimization for all indicators for future versions of NinjaTrader.

[sledge]

Create an infinite loop in your strategy.

Generally I try to search these forums before asking a question, but in this case I don't know what to search for.

Suppose CalculateOnBarClose=false. If my OnBarUpdate() method includes code that takes longer to execute than the interval between ticks, what happens? Does a new OnBarUpdate() event fire off each time a tick comes in, causing a delayed pile-up of calls to this method (or worse, multiple concurrent executions of the same OnBarUpdate() method)? Or does each call of OnBarUpdate(
) block further tick events from calling it until it completes?

The desired behavior for me would be for OnBarUpdate() to block further calls to it until it's done, to ensure that it can execute completely from beginning to end. If ticks must be skipped to facilitate OnBarUpdate() finishing execution, that's fine. I don't want a delay to accumulate because the code is slow.

-Alex

[anachronist]

I have forwarded the issue with development, who reported back, that they are already looking into across the board optimization for all indicators for future versions of NinjaTrader.

That's good to know. If they want anything I've done, feel free to ask. I've been going through the indicators that use internal loops and optimizing them to use no loops and less memory. If I am duplicating an effort already underway, I'll stop with the collection I described above.

One other thing that I would REALLY like to see is exposure of some key internal values in some indicators. For example, the LinReg indicator calculates the slope and intercept. It would be nice to serialize this internal slope and intercept, so that if I need them in addition to the LinReg value, I don't have to waste CPU cycles calculating them separately. I do this now for my fast version of LinReg -- in fact, my fast LinRegSlope and LinRegIntercept simply call LinReg and access the Slope or Intercept properties, respectively. It's also useful in StdDev to expose a property for the mean value. Exposing this makes it more efficient for other indicators and strategies to perform internal calculations (like a Bollinger Band) from one call to StdDev..

-Alex

[sledge]

You are missing your calling.

You should be selling these optimized versions

That's good to know. If they want anything I've done, feel free to ask. I've been going through the indicators that use internal loops and optimizing them to use no loops and less memory. If I am duplicating an effort already underway, I'll stop with the collection I described above.

One other thing that I would REALLY like to see is exposure of some key internal values in some indicators. For example, the LinReg indicator calculates the slope and intercept. It would be nice to serialize this internal slope and intercept, so that if I need them in addition to the LinReg value, I don't have to waste CPU cycles calculating them separately. I do this now for my fast version of LinReg -- in fact, my fast LinRegSlope and LinRegIntercept simply call LinReg and access the Slope or Intercept properties, respectively. It's also useful in StdDev to expose a property for the mean value. Exposing this makes it more efficient for other indicators and strategies to perform internal calculations (like a Bollinger Band) from one call to StdDev..

-Alex

[NinjaTrader_Joydeep]

Hello anachronist,
Thanks again. I will forward your note to development.

[anachronist]

You are missing your calling.

You should be selling these optimized versions

Nah, too much trouble. My plate is full enough without having customers bug me with support requests and whatnot. I get that already from code I've uploaded to the file area, people asking me to make modifications for them, for free.

There's nothing really proprietary about these optimized indicators although I guess it isn't as obvious from the code that they get the same results as the traditional slow versions.
-Alex