Heavy Processor Load - Script Execution Protocol - Multi-Instrument Studies in Study

[Griesha_uk]

I have started testing an new indicator that "calls" 3 other custom studies. Each of these utilises multiple instruments and plots.

I have (successfully) tested each of the "called" indicators individually, on 1 minute ES chart. They are not overlays and paint in a seperate panel below the main chart panel.

These have now been combined into a single (COMB) study that "calls" all 3 sub-studies. This is being tested now and, (whilst it seems to work ok) it is causing significant processor load, so I suspect that the way the studies execute, internally, is non-optimal. Hence my mention of "Execution Protocol" - which I may not understand well enough yet.

The COMB study has AddDataSeries for each of the additional 11 instruments used in sub-studies.

When I increment the Plot values on each OnBarUpdate, the study works, but I get extreme processor usage. When I only update when BarsInProgress == 0, I get a tolerable processor usage, but I get many small gaps in the displayed line/histogram (See attachment).

Are there some general rules surrounding script execution protocol/sequence I need to know ? Is there a solution to my problem?

Suggestions welcome.

[NinjaTrader_Jesse]

Hello Griesha_uk,

From the given details it would be hard to say why that adds a lot more processor usage. You would need to debug the use case to see which specific code is causing a lot of use and then check what code is being used for the added series.

Multi series processing is not specifically going to add a lot more processor use, you would see additional data loaded and OnBarUpdate is called for each series. Depending on the settings used and code used you may be running into a situation where something in the code needs to be further optimized to avoid any extra processor use.

[Vikuno1]

I have started testing an new indicator that "calls" 3 other custom studies. Each of these utilises multiple instruments and plots.

I have (successfully) tested each of the "called" indicators individually, on 1 minute ES chart. They are not overlays and paint in a seperate panel below the main chart panel.

These have now been combined into a single (COMB) study that "calls" all 3 sub-studies. This is being tested now and, (whilst it seems to work ok) it is causing significant processor load, so I suspect that the way the studies execute, internally, is non-optimal. Hence my mention of "Execution Protocol" - which I may not understand well enough yet.

The COMB study has AddDataSeries for each of the additional 11 instruments used in sub-studies.

When I increment the Plot values on each OnBarUpdate, the study works, but I get extreme processor usage. When I only update when BarsInProgress == 0, I get a tolerable processor usage, but I get many small gaps in the displayed line/histogram (See attachment).

Are there some general rules surrounding script execution protocol/sequence I need to know ? Is there a solution to my problem?

Suggestions welcome.

Do you use Drawing objects? I saw something similar when I was using Drawing objects, too many would crash some computers and slow mine down a ton. Especially if they are plotting a ton.

Solution if you are using Drawing objects would be to convert to SharpDX drawings in OnRender.

They have a "SampleCustomRender" which helps show you how to use it if you are unfamiliar (I was)

[Griesha_uk]

Since I first posted this (10 days ago) I have done a thorough review of all the code. I have been careful to always check for appropriate BarsInProgress() when getting input from sub-studies. I also Plot on each OnBarUpdate() (i.e. ALL instances of BarsInProgress() ).

In addition, I have done a Database Repair/Reset and reloaded (repair) the NT8 platform.

I seem to have cured the high processor usage, but now have a perplexing problem that prevents the COMB plot from painting correctly, and can cause some freezing of (ES, NQ, YM) charts.

On study 3 (above) I have base chart ES (BarsInProgress(0)) with additional series NQ (1) and YM (2). This study works perfectly when added to a 1 min ES chart but behaves differently when "called" from the COMB study (with the same default parameters).

When "called" from COMB:

In the 2nd attachment you will see that YM and NQ values "bleed" into ES values (Closes[0][0]). The 1st attachment shows a snip of the code from Study 3 that produces the Output.

So, I'm dead in the water unless this problem can be resolved.

Thoughts/suggestions?

PS. Vikuno1 Thanks for your input. In the COMB study I do manually "Draw.Line()" my histogram cuz NT8 always assumes a base of zero. My study requires a base of 5, so I have no alternative. This hasn't been a problem until the above "perplexalate" arose. This also causes study to not draw these lines. If fixing the "perplexalate" does not cure this, I will post additional information.

[NinjaTrader_Jesse]

Hello Griesha_uk,

If the script is not plotting correct after the changes you made you would have to review what you changed and fix the code to accommodate how you want it to plot.

Freezing of a chart would be an unexpected result when using NinjaScript, if that is happening some logic you are using is still likely having some kind of a problem.

Describing what you are doing not necessarily helpful as we cannot see what specific code is used when the problem happens. You would need to isolate what part of your code causes the freezing and then extract that into a new script to simplify the test. The best way forward is to greatly simplify what you are doing until the problems do not appear and then compare that to your original code to see what may be related to the issue.

[Griesha_uk]

Hi Jesse,

I have spent a rather large amount of time trying to fathom why my (complex/compound) indicator was not plotting correctly and was causing charts to hang.
I have finally found an approach that seems to solve that problem. You see, I was using ES 12-23 as the Data Series instrument, and adding the additional series I needed (such as NQ, YM) within specific indicator code. I was using ES values within the code also.
What I have now done is to use the 6E 12-23 instrument as the Data Series instead, and add the ES 12-23 series within the appropriate indicators. I never access the 6E series within the code.
This seems to have stopped the bleed between the ES, NQ and YM series.

I cannot fully test this until Monday’s Day Session is active, so I will have to post again after that.
It’s also worth mentioning that the bleeding problem also seems to have caused an FCM error (see attached). I have separately been advised how to remove this, so it is not a problem for me right now.

New Anomaly
In the meantime, another anomaly has appeared. I am getting my manually drawn histogram (utilising Draw.Line) appearing on the price panel, rather than the indicator panel.
I have tried to manually put in the value for “this” in the Draw.Line code, but have hit a brick wall. What could I use?
Please see attachments….
Suggestions welcome.
G.

[NinjaTrader_Jesse]

Hello Griesha_uk,

Draw.Line is a NinjaScript method so that does not create manually drawn lines. For the items to appear in the indicator panel the indicator in that panel needs to draw the object and that indicator needs to have DrawOnPricePanel set to false.

https://ninjatrader.com/support/helpGuides/nt8/drawonpricepanel.htm?zoom_highlightsub=DrawOnPricePanel

[Griesha_uk]

Jesse,

For some reason I already had that line, but commented out. I have now reinstated it. I had to remove the indicator from the indicator list (and then re-add it) for it all to work.

Everything just fine now (fingers crossed).

Many thanks,

G.