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)
The TSI is a NinjaTrader default indicator, itis not the worst indicator that I have seen. At least it calculates correctly.
I have tried to use the FirstTickOfBar() condition for many indicators, and it does not always improve performance. The problem is that I do not know what NinjaTrader does if I check for FirstTickOfBar ...
In this case the FirstTickOfBar condition would just save me a few multiplications, so I would not consider it worth using FirstTickOfBar. This does not invalidate the concept. For one of my MTF VWAPs, I was certainly able to improve performance over 1,000 times during news releases, by using both FirstTickOfBar and a recursive formula. It all depends what is in the bracket.
For the TSI I just would take out the divisions into OnStartUp(). This gives me a piglet without lipstick. The gain in performance was not measurable.
During the lifetime of any bar, the output values of any DataSeries that have an index value other than zero do not change. Therefore the calculation of any algebraic expressions involving terms such as Close[1] only needs to be done OnFirstTickOfBar, NOT on every tick. There are about half a dozen of these expressions that can be isolated in Blau TSI. Some have arithmetic divisions in them, so not doing them on every tick is a big help since division is costly per Gomi.
I was surprised to see so much interest in this post... good!
@gomi, doesn't the calculation of 1/x entail division? Is multiplying by 1/x less costly than dividing by x?
FatTails, the piglet is so cute, what is his name? Does he have a FacebookŽ page?
Three things about FirstTickOfBar that we need to be aware of:
For historical data it is actually LAST Tick of Bar.
In a multiseries indicator you will get crazy results unless you are specific to a barsarray series For example If(BarsInPRogress==0 && FirstTickOfBar)
By the time FirstTickOfBar is true, the values of all the variables have ALREADY been set to the values appropriate to the new bar.
Of course calculation of 1/x implies a division, that's why I mentioned "if you have lost of divisions by a rarely changing x", so you can only make the division once , and use the result afterwards.
Also remember that with NT , you're likely to see the improvement only on very heavy numerical computations...
There are now two complementary approaches that, together, will give a big performance boost to Ninjatrader. And there is only one place on the web where you will find this information... Big Mike's. The two approaches are:
Reducing resource usage of indicators
Moving the historical chart and replay data from the System Disk to a faster or less busy device, ideally a RAM disk but alternately a non system SSD or HDD, as discussed in
I have been able to make a large performance gain in NT 7 by storing the NT database files on a RAM drive and I thought that I would share what I have done.
The time taken by NT to change the time frame of a chart from 3 to 5 minutes was 46 seconds and …
Regarding the first item:
What is being called "Optimizing" of code should not be confused with the process of optimizing a strategy by adjusting parameters. Maybe code improvement should be referred to as "Economizing".
I think that the CPU consumption of some indicators can easily be reduced by one or two orders of magnitude (90 to 99%) however, I have never tried to measure the change in performance. I think this could be done by inserting code into a control version and an economized version of an indicator that would measure, and print to the output window, things like the total time in ms to backfill historical data, and the total time per bar spent processing OnBarUpdate events.
Hello,
I agree with the previous post. There is nothing better than outputting/printing time to the output window before and after critical chunks of code to figure out the bottleneck. Pay attention to variables, array size for memory, switch statements instead of if/else where applicable and use of Ninja's multi threading. ( using OnMarketUpdate with OnBarUpdate to divvy up the functions as they will be called at different events but may accomplish the task faster together)
