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)
More on performance: does minimizing a chart, or having it on a non-selected tab, improve performance, compared to just having it open and in view?
Yesterday I posted a question on the NT support forum about when a chart that is minimized or on a non-current tab (on a tabbed window but not the selected tab for that window) gets updated.
The reason was that I thought I recalled from NT7 that minimized charts are not updated, and I wanted to know if, in NT8, the same is true, and if it is also true of tabbed charts that are not on the selected tab. This is important because I am trying to reduce CPU usage, and I wanted to know whether I should just minimize a bunch of charts that I currently have on tabs.
I am not completely comfortable with the answer, and, if possible, I would ask @NinjaTrader to weigh in and confirm or correct the response. I think it is important for users to understand this situation.
Here's his first reply, which is that minimizing doesn't matter:
Well, this bothered me, because the Help file does seem to say something different. So this was my reply:
The final reply from Dennis was:
Sorry for all this quoting, but I wanted to lay out the entire picture as I currently have it.
Where it stands now seems to be:
1. All charts, minimized or not, tabbed and selected or not, will have their price data updated as usual.
2. Minimized charts will not have their indicators updated so long as they are in a minimized state. Since we are told that indicator calculation can be a major performance issue, this is important.
3. Apparently there are other "suspended" states a chart can be in, which includes "background tabs" (I think this is my original question) and background workspaces. In these cases, the indicators are also not calculated or updated, but the basic chart price data is.
The upshot would be that minimizing a chart will help somewhat, because it suspends the indicators, and also that a chart on a non-selected tab or even a non-selected workspace will not have its indicators updated -- but in all cases, the chart data is still actively updated, so the performance gain is there, but not as much as I had hoped.
I wanted to share this out with the other members, because I think it's pretty important. And also, because it is important, and because the quoted passage in the Help file seems to say something different when it refers to a chart being "suspended," I did want to see if @NinjaTrader will confirm or amend this understanding. Perhaps I was just reading too much into the word "suspended," but I would like to be sure this is cleared up.
Your understanding is correct. To simplify this further, all this means is that when a chart is not in view (minimized, on an non-selected tab etc...) the indicator's OnBarUpdate() method is not called thus saving CPU cycles.
Disclosure: This communication is sent to you by NinjaTrader, LLC, a software development company which owns and supports all proprietary technology relating to and including the NinjaTrader trading platform.
... I wanted to respond immediately; perhaps, I'm getting some wisdom (finally).
Just in case we are confusing coding indicators with actual trading: nothing is more important for the Independent than EXECUTION. And, all that it entails... it's deep topic.
My initial post was regarding the NT8 SuperDOM puking under easier market conditions than '07. That in and of itself is unacceptable for such a anticipated and "advanced" platform. But, it got me to thinking: if it pukes under some medium market stress, what are the unforeseen costs due to platform slippage on a day to day basis?
Let's say you complete ten /ES trades a day. Poor execution, slippage, lag whatever you want to call it... is costing you a tick on each end: $25. And, let's say you trade 200 days a year... 2000 trades X $25 = $50,000. Just based on a (1) lot. And, this doesn't include the losses when the platform pukes or missed opportunity because you are doing your third system re-build for the year.
Do indicators that are not marked "Visible" still recalculate and use system resources? -- Part 2 (Correction)
I put up a post just a few hours ago, discussing the question of whether checking or unchecking the "Visible" property of an indicator will cause it to consume computer resources. The substance of the post was that a non-Visible-checked indicator would still use CPU cycles, which was based on a reply I received from NT support.
I have received a PM from @NinjaTrader that this information was in error, and that the original support response has been corrected.
So the correct information is that an indicator that is set to be not Visible in its properties does NOT continue to consume PC resources.
This is important information to have, and thanks to Ray for making sure that the correct info is out there. Here's the link to the corrected post on the NT support forum: https://forum.ninjatrader.com/showthread.php?p=538632
I have corrected my original post.
I hope everyone who saw the original also sees this correction.
Since I had this post here a few days ago about performance issues with NT8, I want to give an update after taking into account what I have been learning about NT8's processing of charts and indicators, which has been covered in recent posts in this thread.
Basically, I have had no issues since I reduced the load that I was asking my PC to handle. I now have only a few charts, all on tabs in one window, fewer indicators (but still not exactly "clean" charts ), nothing minimized and no other workspaces open. Essentially, I do have the charts up that I need, but have taken out everything that was unnecessary. I don't think I have had to cut back anything that I needed to have.
With this (as well as upgrading to 13.1, which may or may not have helped), performance has been fine.
I just wanted to round out the discussion with the outcome of the changes that were based on the info from NT, plus my being realistic about what I really needed. Your mileage may vary, but I'm not seeing a problem now.
I've been doing a lot of Market Replay lately, and came across a couple of issues with the slider and the Go To control. I put up a post on the NT support site, which I'll quote here in case anyone else runs into them:
------------------
I've run into two related features in Market Replay that create unnecessary delay in using it:
1. Say you open the Replay connection and it starts at midnight on a date you have Replay data for. You want to skip ahead to, say, the ES RTH open at 9:30 ET on that date, so you click on Go To and enter the time. Instead of jumping to the new time and refreshing the chart, Replay draws the price bars, one at a time, until it gets to the specified time. It does it at a fairly good rate of speed, but it still takes a long time to paint each bar, and it doesn't really go that fast either. (Same happens if you move the slider instead of using Go To.)
2. Once you're at a point on the chart, say you want to skip ahead 5 minutes. I assumed you could just use Go To or the slider to move along another 5 minutes from where you are.... But in fact, NT8 goes BACK to the start of the day, and then laboriously paints each bar again, until it reaches the bar 5 minutes ahead of where you were.
I am sure that both of these behaviors are deliberate design features, and they do work as designed, so they're not bugs, but I think the design idea is clearly wrong. No one wants the "jump to" to take this much time and to laboriously paint every bar one by one, and certainly no one wants to have to start over at the beginning just to move ahead from a current location.
The user workaround for issue #2 obviously is to just turn the replay speed up to a high number and move ahead to the time you want, rather than use Go To and have to start again at the beginning. But this caught me a couple of times until I realized I didn't really want to use Go To or the slider unless I had to.
I would appreciate it if someone could look into this and change this behavior, so that both Go To and the slider
(1) don't have to paint the chart, bar by bar, just to move from the beginning to the desired time, and
(2) don't have to go back to the earliest point in the file and repaint all the bars just to move ahead from the current bar, but instead starts from right where it is.
Correct, it is working the way it was designed in NT8 (IE running each tick from the beginning of replay date to start date/time) so I will take your request into a feature request. If a feature request already exists, then your vote will be added to it.
I will update this request when I have further information. Thanks in advance for your patience and we appreciate the feedback on this topic.
----------------
So, it's one more thing on the list, and it's obviously not the most important they have. But at least it's on there.
It turns out that the feature request to change the strange behavior of the slider/Go To control was already on the list.
Also, apparently if anyone wants to help this change by improving its priority, they should go to the previously-mentioned thread and tell NT you vote for the change. Here's the latest reply from NT support:
I guess this voting thing is how they decide what's an important change for their users. There are obviously more important things, but if you use Replay you will want to get this fixed.... Unless you enjoy losing your temper while waiting for something unnecessary to crawl to a finish.