Reducing CPU load of NinjaTrader

December 3rd, 2010, 05:17 PM

Got this answer from Dierk who kindly responded to my question:

The Draw() methods create objects which are redrawn whenever a chart is repainted which is triggered by logic below. *)

Obviously the Draw() methods in your code would be called whenever OnBarUpdate() is triggered which could be down to the tick (COBC=false).

*) However, here is some info: IndicatorBase.Plot() call frequency is primarily impacted by the chart update frequency. Although there might be additional situations where the chart (and indicators) would require repainting.

As far as I have observed it is the repainting of the objects that consumes CPU power. If you cover a chart, it will not be repainted and the CPU load is quickly reduced.

December 3rd, 2010, 09:37 PM

Fat Tails

As far as I have observed it is the repainting of the objects that consumes CPU power. If you cover a chart, it will not be repainted and the CPU load is quickly reduced.

Yes, that corresponds to my experience too. I minimize any chart I'm not looking at. You can experiment with all this using market replay, too.

August 12th, 2011, 11:36 AM

Fat Tails

Got this answer from Dierk who kindly responded to my question:

The Draw() methods create objects which are redrawn whenever a chart is repainted which is triggered by logic below. *)

Obviously the Draw() methods in your code would be called whenever OnBarUpdate() is triggered which could be down to the tick (COBC=false).

*) However, here is some info: IndicatorBase.Plot() call frequency is primarily impacted by the chart update frequency. Although there might be additional situations where the chart (and indicators) would require repainting.

As far as I have observed it is the repainting of the objects that consumes CPU power. If you cover a chart, it will not be repainted and the CPU load is quickly reduced.

Looking through some older posts - again, thanks for this!

I have removed most of the Draw statements from my indicators and what used to be big spikes in my 6-core 4.2Ghz CPU has calmed down even with news events.

While I like the aesthetics of clouds created with DrawRegion, it clearly created performance issues along with some other Draw commands.

August 12th, 2011, 12:33 PM

Tarkus11

Looking through some older posts - again, thanks for this!

I have removed most of the Draw statements from my indicators and what used to be big spikes in my 6-core 4.2Ghz CPU has calmed down even with news events.

While I like the aesthetics of clouds created with DrawRegion, it clearly created performance issues along with some other Draw commands.

You can also limit the draw objects by using a lookback period from now and only draw them within that lookback period. You will then have them on today's chart, but not on the chart section a few days ago.

August 12th, 2011, 06:54 PM

After observing this for a day and not having any "Not Responding" issues on the charts, I can say IMO this Draw issue is so severe that NT should include a warning on their use.

Fri was not as wild as Mon, and there were no big news announcements, but so far, so good...

In the past I have included some "cloud" coloring code in my indicators for aesthetics (and it also removes any visual ambiguity in a chart when sending an image of it), but the performance impact on live charts is horrendous.

So I now bracket that logic with a bool, so I can turn it on/off as a parameter. That way I can turn it on during off-time or when capturing an image, but leave it off while the chart is being updated.

Tweaking the efficiency of the Draw routines and the ability to use multi-cores during live updates is what I would put on the top of the "to do" list, but they probably are at NT anyway....

August 13th, 2011, 04:59 AM

Tarkus11

After observing this for a day and not having any "Not Responding" issues on the charts, I can say IMO this Draw issue is so severe that NT should include a warning on their use.

Fri was not as wild as Mon, and there were no big news announcements, but so far, so good...

In the past I have included some "cloud" coloring code in my indicators for aesthetics (and it also removes any visual ambiguity in a chart when sending an image of it), but the performance impact on live charts is horrendous.

So I now bracket that logic with a bool, so I can turn it on/off as a parameter. That way I can turn it on during off-time or when capturing an image, but leave it off while the chart is being updated.

Tweaking the efficiency of the Draw routines and the ability to use multi-cores during live updates is what I would put on the top of the "to do" list, but they probably are at NT anyway....

If you use indicators, which draw clouds or colored channels, you should use them in setting CalculateOnBarClose = true. This should avoid a freeze.

I also use a bracket to a exclude the drawing of regions and rectangles. I do not have a separate Boolean, but use the opacity.. If it is set to 0, the part of the code with the Draw() methods is not executed, here an example from the TWAP V36

Code

if (Opacity1 != 0)
{
     DrawRegion("upper1"+ startBar, sessionBar-1, 0, UpperBand1, SessionTWAP, Color.Transparent, InnerAreaColor, Opacity1);
     DrawRegion("lower1"+ startBar, sessionBar-1, 0, SessionTWAP, LowerBand1, Color.Transparent, InnerAreaColor, Opacity1);
}

August 13th, 2011, 07:43 AM

I had freeze/slow problems all week with the increased volume in 6e. I have a quad core, 3g mem... I reinstalled ninja, went to empty workspace and created a new chart and it was still slow. When I loaded up indicators on the chart it slowed up more. The cpu meter would max out on approx 25% when normally I have cpu usage of 3-6%.

Also the cursor would not respond quickly moving across the charts. Can't trade if you think you might be lagging the real time market.

No severe problems like this prior to this week. And all goes back to normal when volume drops off.. My computer guru buddy heard that there is a problem with quad cpu's and nt7. Anyone else have info on this?? I cut my processors down to 2 and now I get normal cpu spikes above 25%. That was late day on Friday so I'll have to wait until Monday to see if it works

Other suggestions I have read on blogs today: update video drivers, delete old version of .net, repair database, delete mdb.....

August 13th, 2011, 08:48 AM

gkinlaw

I had freeze/slow problems all week with the increased volume in 6e. I have a quad core, 3g mem... I reinstalled ninja, went to empty workspace and created a new chart and it was still slow. When I loaded up indicators on the chart it slowed up more. The cpu meter would max out on approx 25% when normally I have cpu usage of 3-6%.

Also the cursor would not respond quickly moving across the charts. Can't trade if you think you might be lagging the real time market.

No severe problems like this prior to this week. And all goes back to normal when volume drops off.. My computer guru buddy heard that there is a problem with quad cpu's and nt7. Anyone else have info on this?? I cut my processors down to 2 and now I get normal cpu spikes above 25%. That was late day on Friday so I'll have to wait until Monday to see if it works

Other suggestions I have read on blogs today: update video drivers, delete old version of .net, repair database, delete mdb.....

You should be able to test before Monday by using replay data under File/Download Replay Data...

I have a 6-core CPU but NT single-threads live charts anyway. Since turbo-mode of the chip can boost 3 cores to 4.2Ghz for those type of apps, I force NT to use the faster cores by setting the startup property of my NT-64bit icon (got this from a user on the NT forum)

C:\Windows\System32\cmd.exe /C start "NinjaTrader 7" /HIGH /AFFINITY 0x7 "C:\Program Files (x86)\NinjaTrader 7\bin64\NinjaTrader.exe"

This sets NT to High Priority and the Affinity to use the 1st 3 cores (doesn't matter which one since all 3 are turbo-boosted).

If your indicators use a lot of Draws you might want to exclude them if you can. Also try the suggestion of minimizing to the Taskbar charts you don't constantly watch to lighten the re-draws that the CPU has to perform.

I am not sure if NT is offloading screen updates to the GPU using WPF - I have a decent video card (not great, but good enough) and I would hope it is being used to take some stress off the CPU.....

EDIT:

I guess not

https://forum.ninjatrader.com/showthread.php?t=11898

Will NT 7's charts be based on Windows Presentation Foundation (WPF) or WinForms?

It will be based on WinForms.

August 13th, 2011, 02:22 PM

gkinlaw

Ihe cpu meter would max out on approx 25%

If you have a quad core CPU, then this indicates NinjaTrader's single-threaded design is the culprit. For charting, NinjaTrader can only use one CPU thread at a time, last time I checked.

Usually this is due to an indicator. If you run NinjaTrader with no indicators, you shouldn't see this problem.

Mike

August 15th, 2011, 07:32 AM

Big Mike

If you have a quad core CPU, then this indicates NinjaTrader's single-threaded design is the culprit. For charting, NinjaTrader can only use one CPU thread at a time, last time I checked.

Usually this is due to an indicator. If you run NinjaTrader with no indicators, you shouldn't see this problem.

Mike

Here's an image of the task mgr with 2 cpu's running, I get spike's now instead of capping off at 25%. Also yesterday I found that I was recording data in Jan 1. and I cut that off. Bet that used up some cpu.

thanks for you replies!!

Reducing CPU load of NinjaTrader

Discussion in NinjaTrader

Reducing CPU load of NinjaTrader