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 use quite a few indicators for my workspaces, and as I do not use multiple quadcore processors, I want to limit the CPU load caused by NinjaTrader. Besides setting most of the custom indicator to "CalcOnBarClose = true", I am currently experimenting with the custom plots of some indicators. Even if an indicator is set to "CalcOnBarClose = false", the custom plot seems to be triggered with each incoming tick. If calculations are performed within that plot, this may slow down NinjaTrader.
So this is my idea: Collect the values and the GraphicPath objects to be plotted, store them in a cache and retrieve them from there without recalculating them with every incoming tick. Only perform calculations, if
(a) a new bar has been completed or
(b) the vertical or horizontal compression of the chart has been changed by the user
I really do not know whether this makes sense, but anyhow I have applied the concept to the default pivots indicator of NinjaTrader. This model could be applied to other indicators as well, which use custom plots and which do not need to recalculate the plots with every incoming tick.
These are the changes that I made:
Variables
public override void Plot()
Does this make sense? I have attached the modified indicator and am now looking for some pundits
- to validate or invalidate the idea
- and, maybe, test the indicator attached
First, Plot() does not get called for every tick. It can, but if there is a burst of ticks, the Plot() call should get delayed and only called after the display update interval specified in the chart properties.
I think your idea has merit, but you have to be careful since you don't know what Ninja is really doing behind the scenes. For example, what if the chart required a refresh, but your cached values were right so you did not do a refresh? I think this is a rare occurrence, but I just wanted to point out that you may not have complete control since Ninja does not really document this functionality.
How much CPU are you using? Is it only an issue during a quick burst?
Thanks for the answer. First, I was not aware that I could set the display update interval via chart properties. Are you sure that this setting also applies to custom plots? I had a bad experience with the pivots at some stage, where they caused about 30% processor load. Citing Josh from NinjaTrader:
There were calculations being done in the Plot method of the Pivots indicator that was expensive performance wise and it was being done multiple times. So, yes, it was moved away to be less intensive. Development says it is unlikely you would run into the same issue with your own programmings.
The problem was solved by moving away those calculations in a subroutine, which is called conditionally.
I think that the chart will be refreshed anyhow, and that the changed code only affects the indicator selectively. I also have tested vertical and horizontal chart compression with and without the conditions that I added in the beginning of the Plot() override.
My CPU load is between 25% to 30% with IB feed, which is a compressed feed. So if I used Zenfire or any other real feed, it would be limit. It is not quick bursts but fluctuating between 15% and 30% for the workspace.
I am also afraid that other users might encounter issues, if they use some of the indicators that I have coded. Many of them use the graphic engine of the pivots indicator to display horizontal lines. So if you put five or six of these on your charts, and if you have three or four charts open, the impact can be significant.
Yes, the update interval should affect custom plots as well, because your plot routine is basically just taking the place of the standard Ninja one, it does not know the difference.
Plotting is an area that you do need to be very careful for performance reasons because it has the potential to do a lot of work for a single tick. Allocating resources like brushes and pens is not a good idea, and copies should be kept around. When looping, be sure you are only doing the min amount work necessary.
Ninja is notorious for being rather lazy all over the the place (they have gotten better in NT7 though). You can still see it today, if you go look at their implementations of bar styles (candlesticks etc). They do a lot of little stuff that is not that big a deal by themselves, but they add up rather quickly.
In indicators, there are lots of little tricks you can play (see @fluxsmith ind), but there are trade offs.
At the end of the day, when I decide something is sticking around, I go in and do a deep dive and optimize it so I know I never need to go back and look at it. I do not do this with most indicators though, because I don't use many.
So if Plot() is only called once per chart update interval selected, the impact of the modifications I have done will be small - unless there are some power users who need refresh intervals set to below 0.1 sec, because otherwise they feel that they miss part of the action....
Knowing this, the question is
- whether the modifcation made will contribute to speed in a significant way
- whether it works correctly
- whether it can be improved
At the moment it is just an idea that I wanted to check. If it does not pay off, I might well decide not to go any further with this. I am not running out of ideas. But first want to explore the feasible.
That is the theory, but some indicators force an update (i.e. want to see every update). These are rare, and are discouraged for obvious reasons. 0.1 is the smallest value they allow, so some use the force method to see more updates. In reality though, we really dont know what NT is doing. I suspect there are other cases that cause an immediate update, like auto-scale changes or a new bar being added.
I would suspect that what you are trying to do will be better when you are under load, which is when you want it, but if you are using the update interval and not forcing updates every tick, then the gain will be minimal.
When I ran the IB feed a long , long time ago, I put TWS on a different computer. TWS was pretty bad back then, taking up a lot of CPU. I have no idea about now.
On a single machine with TWS and Ninja pretty much anything is faster.
If I use DrawRectangle() or DrawLine() or any of the other Draw() methods in OnBarUpdate(), will display update intervals as fixed via chart properties apply or will it be calculated with every incoming tick?