Can this be done? Detect if indicator is running in front-loaded workspace

November 20th, 2013, 04:06 PM

As you know, NinjaTrader is set up so that all charts/indicators that are open and running will eat up CPU time, whether they are currently being displayed or not. So if you have 4 charts in one workspace and 4 charts in another workspace, all 8 charts will eat up CPU cycles, even though only 4 are showing.

Is there some way to write C# code inside an indicator to detect if it is running in the currently open workspace? If so, you could short-circuit the calculation code to only run if the chart is being displayed in the current front-loaded workspace, thereby saving CPU cycles. I've already found a way to do this with minimized charts (using the Windows.Forms library), but I'm just wondering if there's some way to hook into NT's code (supported or not) that will allow you to do a check to see if a workspace is currently being displayed on-screen. Actually, I can think of a hack that might work for me if I could do something as simple as just checking the name of the current workspace that a chart window is running in, whether it is currently front-loaded or not. Is there some way to do this?

Thanks!

traderwerks · November 20th, 2013, 06:57 PM

Or you could just close the other workspace and then it would not use any CPU

November 21st, 2013, 02:06 AM

FBJS

As you know, NinjaTrader is set up so that all charts/indicators that are open and running will eat up CPU time, whether they are currently being displayed or not. So if you have 4 charts in one workspace and 4 charts in another workspace, all 8 charts will eat up CPU cycles, even though only 4 are showing.

I think you would be far better served seeing which indicator(s) are consuming most cpu time and either losing or optimising them.

For historical reasons (largely 6.5) Ninja gets a pretty unfair press, I can prove it easily as I run 4-7 concurrent workspaces with multiple charts and loads of home grown heavy drawing indicators in all of them. On my bog standard HP 8core/8Gb i7 it ticks over with 1-2% of cpu and only hits 6-7% under a fast market load, despite of course itself being uselessly single threaded, now that is a shame.

E.g. As an example if you have any indicators that are only price dependent, not volume, then a simple static variable for 'lastClose' and saved/compared to Close[0] in each OnBarUpdate can save loads of time (if its a cpu heavy indicator). Lots of others can be killed even more just by setting CalculateOnBarClose = true, upping the chart timeframe, dumping tick charts, etcetera.

You should be able to find lots of other tips on futures.io (formerly BMT), but first off I would start using the Task Manager and switching charts on and off to find the real culprits.

November 21st, 2013, 01:39 PM

ratfink

E.g. As an example if you have any indicators that are only price dependent, not volume, then a simple static variable for 'lastClose' and saved/compared to Close[0] in each OnBarUpdate can save loads of time (if its a cpu heavy indicator). Lots of others can be killed even more just by setting CalculateOnBarClose = true, upping the chart timeframe, dumping tick charts, etcetera.

Thanks... just wondering, can you show me a snippet of code to demonstrate exactly what you mean by using a static variable like this for Close[0]? I'm still a little unclear on exactly how you implement this...

November 21st, 2013, 02:40 PM

FBJS

Thanks... just wondering, can you show me a snippet of code to demonstrate exactly what you mean by using a static variable like this for Close[0]? I'm still a little unclear on exactly how you implement this...

In usual variables region of indicator class:

Code

    private double  lastClose;

At start of OnBarUpdate:

Code

			// not interested in volume so optimise out same price ticks (lots)
			if (!FirstTickOfBar && Close[0] == lastClose)
				return;
			
			lastClose = Close[0];

So a new bar will always be processed and all new highs/lows are accompanied by changed Close[0]'s as well, so it still sees those.

Have fun! (But do use the TM to identify the greedy ones if you can, and then some will be volume dependent but usually its heavy drawing on lots of redundant price ticks (loads on ES for example)).

edit: Don't really need static in this case, so I'll use private instead. Just normal C#'isms.

November 21st, 2013, 02:57 PM

ratfink

In usual variables region of indicator class:

Code

    private double  lastClose;

At start of OnBarUpdate:

Code

			// not interested in volume so optimise out same price ticks (lots)
			if (!FirstTickOfBar && Close[0] == lastClose)
				return;
			
			lastClose = Close[0];

So a new bar will always be processed and all new highs/lows are accompanied by changed Close[0]'s as well, so it still sees those.

Have fun! (But do use the TM to identify the greedy ones if you can, and then some will be volume dependent but usually its heavy drawing on lots of redundant price ticks (loads on ES for example)).

edit: Don't really need static in this case, so I'll use private instead. Just normal C#'isms.

Hey, thanks a lot! Much appreciated...

November 22nd, 2013, 04:53 AM

FBJS

Hey, thanks a lot! Much appreciated...

You're welcome, another quick change is to go through all your charts and using the 'right-click Properties' menu change all the 'Display update interval's to be longer than the default Ninja 0.5 setting, also make them all different, that way the cpu doesn't always get hit at the same time.

E.g. for my short term charts I use 0.5, 0.6, 0.7, 0.8, 0.9, 1, 1.1, etc, 2.1, 2.2, 2.3 for medium term and 5-15 seconds for longer term charts.

And for working out which are the nasty or badly coded indicators the load-up time on historical charts is probably easier to work from rather than the task manager, but both are well worth the effort.

November 22nd, 2013, 12:50 PM

ratfink

You're welcome, another quick change is to go through all your charts and using the 'right-click Properties' menu change all the 'Display update interval's to be longer than the default Ninja 0.5 setting, also make them all different, that way the cpu doesn't always get hit at the same time.

E.g. for my short term charts I use 0.5, 0.6, 0.7, 0.8, 0.9, 1, 1.1, etc, 2.1, 2.2, 2.3 for medium term and 5-15 seconds for longer term charts.

And for working out which are the nasty or badly coded indicators the load-up time on historical charts is probably easier to work from rather than the task manager, but both are well worth the effort.

Thanks again, that's a great idea about alternating the chart intervals to avoid simultaneous CPU hits. Kind of sad that we have to hack around like this to compensate for the platform, hopefully they will do a better job in NT 8 with optimizing performance. Much appreciated!

Can this be done? Detect if indicator is running in front-loaded workspace

Discussion in NinjaTrader

Can this be done? Detect if indicator is running in front-loaded workspace