Can this be done? Detect if indicator is running in front-loaded workspace
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?
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 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.
The following user says Thank You to ratfink for this post:
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? I'm still a little unclear on exactly how you implement this...
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.
The following 2 users say Thank You to ratfink for this post:
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!
The following user says Thank You to FBJS for this post: