Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I need an indicator to update intrabar, so I cannot use "FirstTickOfBar". I have my chart set to a display update of 0.5 seconds. This means that the chart is updated 120 times per minute. It also means that all calculations performed by Plot() will beexecuted at most 120 times per minute.
During a news release ES is heavily traded, generating maybe 1000 ticks and more. The default setting for the display update prevents NinjaTrader from freezing under these conditions, and the chart can still be updated intrabar. This filtering is applied to Plot().
If I do not override Plot(), but use some of the Draw() methods in OnBarUpdate(), I do not know, whether these will be executed 1000 times per minute (unfiltered) or just 120 times according to the display update settings.
I want to use these methods intrabar, otherwise I would not have put the question here.
If the Draw() methods are causing your charts to update, then you can do similar caching/short cutting to only call it once in your indicators, or only when the anchor point changes.
Yes, that should be possible. But anyhow, try to understand how these Draw() methods work. I have one simple indicator which is supposed to run in CalcOnBarClose = false mode, and as I was lazy to write a custom plot I have employed the Draw() methods to achieve what I wanted.
Just want to know whether there is a risk that this indicator slows down NT.
Reducing CPU load and making more efficient indicators is an admirable goal, don't get me wrong --- but I think for any modern quad core CPU, there should be no issue.
With MultiCharts, even though I only trade CL, I have TF, ES, 6E, DX and YM loaded in the background. Each workspace has 5 charts (CL has 6). They are all running on what Ninja would call "COBC false" with a couple of indicators per chart.
My total CPU usage is about 3%. I see spikes to 10% every now and then, but rare. I have a i7 920 overclocked to 4ghz.
This machine is already two years old (well, 21 months). So really any quad core CPU bought in the last 4 years is probably more than fast enough to not worry about this per-tick stuff.
You are funny. Not everybody has a quad core CPU, I don't. My equipment is three years old and has a dual core CPU. Also my questions were relating to NinjaTrader, not to MultiCharts.
CPU load for my default workspace typically oscillates between 20% and 40%. I have had no freezes and there are no problems, but I need to monitor CPU load. And everybody who runs NinjaTrader on equipment which is not the newest generation should as well.
RAM usage has gone down considerably with NT 7.0, but CPU load has increased, as they have optimized against it.
If there was no CPU problem, I would not have started this thread.
Cacheman will only help for memory/disk caching problems.
Some of @Fat Tails indicators needs a lot of data, so a lot of things to compute, memory or disk access time is not the problem, it's the CPU itself.
As NT multi-thread capabilities are not perfect, the easier solution is to use a fast CPU, having more than 4 cores won't help a lot, imho.
It is not the amount of data that causes the problem. The FibonacciZones indicator, which uses a comparatively large data base, does not create any CPU load at all, because no calculations are performed with incoming ticks. Even with the bar close there is little excitement as recursive formulae are used and calculations are only performed if needed. There are two sources of CPU problems
(a) indicators that need to run in "CalcOnBarClose = False" mode
(b) extensive calculations that are being performed in Plot() also affect the indicators that run in "CalcOnBarClose= true" mode, I have had the case where the Plot() section of a single indicator caused a CPU load of about 30%.