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)
Here is an indicator that uses optimization techniques including predefined instances of external indicators and minimization of the number of calls to the MIN and MAX indicators.
As a result, this indicator loads and refreshes super fast.
Thanks again to Richard Todd for explaining the how and why of these techniques.
I hope that some of you will take the time to look at this code and use these techniques in your own work.
Gumphrie recently posted a Zero Lag Double Stochastic on the Ninjatrader forums. I optimized the code and modified it to use an external call to my super fast Double Stochastics Optimized instead of the inefficient "stock" version.
You will note that …
Our MIN/MAX indicators have been re-written in NT7 Beta 17. There is a known bug with this that is resolved for Beta 18. Point being, no need to roll your own MIN/MAX functions. We are also going through all our system indicators to see if we can make some further improvements where it would make a difference.
In Double Stochastics Optimized (DSCO), I did two things to reduce the number of times that the MIN and MAX functions would be called in the first place. Reason: these functions do loop processing, so are expensive to run.
Made sure that each one could be called no more than once per bar, on FirstTickOfBar.
Made sure that even then, each one would be called only when the item last removed from the series, or the item most recently added to the series, could have an effect on what the MIN or MAX indicator would return.
Then, I moved the code from the MIN and MAX indicators into the DSCO indicator itself. I used the same code Ninja used in the original MIN and MAX indicators.
I did this based on the theory that calling a private function might be more efficient than calling an external indicator, however I am not sure about that.
There is a tremendous decrease in loading and refresh time vs. the @DoubleStochastics indicator. I think it's mostly because the number of executions of the MIN and MAX loops has been reduced by a couple of orders of magnitude.
Exactly! All of the nested stuff makes it easy to write code, but you pay a price. The built in stuff makes it easy to get up and running and try things out. Once you know it is working though, you can go back and optimize it greatly, if it is really needed.
I don't really use indicators anymore, but when I did, I had coded most of my indicators to remove all of the nested stuff (especially the trivial stuff like MIN/MAX).
As 'Ninjatrader' stated, MIN and MAX iterating when not required is fixed in b18. As I see it the two biggest efficiency problems are iteration and memory consumption. I just posted jhlMIN and jhlMAX which when used in building other indicators and not displayed have memory overhead of 8 * n + 16, vs. I believe over 2K for the standard implementations.
Post #70 in this thread is a perfect example of what not to do. The writer, xxxx72, talks about his programming background, his expert observations regarding NT7, and his scheme to reduce CPU load by skipping OnBarUpdate cycles.
However he failed to correct some extremely obvious and totally ridiculous features of the original code that were the real causes of the poor performance. Adding sampling of intrabar ticks while ignoring the deficiencies of the bar update code is a wonderful example of putting lipstick on a pig.
Here are the major problems:
Variables that only need to be calculated once (ONCE, not once per bar) are being calculated on every tick. These variables retain constant values over the entire life span of each instance of the indicator.
Variables that only need to be calculated once per bar are also being calculated on every tick. Avoiding that situation is why God gave us the if(FirstTickOfBar) condition.
These problems were a cinch to fix. I guess you have to be a non-programmer like me to notice things like that. C'mon guys, this is inexcusable.
Just a remark if lots of divisions are involved : remember on a pure performance perspective that division takes much longer than multiplication.
So if you have lost of divisions by a rarely changing x, it's much faster to compute invx=1/x once, and perform multiplications by invx rather than divisions by x.
