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)
Efficient Code for finding highest high and lowest lows of a range of bars.
So, my dilemma is this... I've been trying to create clean, efficient code and I've seen others do two things:
1. Use Methods they have created and then call from their main indicator (UserDefinedMethods).
2. Create an indicator and then use its results similar to how you are suggesting above.
I'd like to create the fastest code possible and wonder if doing either of the above will slow my code down as opposed to keeping everything in the one indicator.
I did find a good pdf by Richard Todd, https://richardtodd.name/docs/pdf/efficientNinjaScript.pdf, that also talks about your method above.
So, for number 1, if I pull out code that is used in many different indicators and place this common code into a userdefinedmethod file, does my indicator run slower? My guess on this one is probably not.
Although number 2 appeals to me since I can create simple building blocks and use them in the main indicator, does Ninja end up using more resources? i.e. say for instance the building block utilizes a DataSeries in its code and then a variable is created in the main indicator of the building block type, as you show above, is Ninja then using twice the resources (2 DataSeries now instead of just one, compared to if I made one large indicator)?
I hope this makes sense... if not, please let me know & I'll try to explain it better. (I'm not a programmer by profession and C# is new to me.)
So, my dilemma is this... I've been trying to create clean, efficient code and I've seen others do two things:
1. Use Methods they have created and then call from their main indicator (UserDefinedMethods).
2. Create an indicator and then use its results similar to how you are suggesting above.
I'd like to create the fastest code possible and wonder if doing either of the above will slow my code down as opposed to keeping everything in the one indicator.
I did find a good pdf by Richard Todd, https://richardtodd.name/docs/pdf/efficientNinjaScript.pdf, that also talks about your method above.
So, for number 1, if I pull out code that is used in many different indicators and place this common code into a userdefinedmethod file, does my indicator run slower? My guess on this one is probably not.
Richard W. Todd is an expert virtuoso programmer who knows what he is talking about. The posts he made (as user "Richard") in the code optimization thread that ZTR started on futures.io (formerly BMT) were exceptionally valuable.
The only thing that would be faster than using the predefined instances of the MAX indicator would be putting the code of the MAX indicator INSIDE your indicator as one of its custom methods. I don't think the small performance improvement would be worth the trouble. You DO want to call the MAX function as infrequently as possible since it will sometimes iterate through a loop.
Ninjatrader's new improved version of MAX, which was suggested to them by RWT, does not do that nearly as often as the old one did. It uses logic tests to avoid unnecessary looping. But it's better to not do even those when a call to MAX is not needed at all.
If you send me your code in a PM, I will review it.
Richard W. Todd is an expert virtuoso programmer who knows what he is talking about. The posts he made (as user "Richard") in the code optimization thread that ZTR started on futures.io (formerly BMT) were exceptionally valuable.
The only thing that would be faster than using the predefined instances of the MAX indicator would be putting the code of the MAX indicator INSIDE your indicator as one of its custom methods. I don't think the small performance improvement would be worth the trouble. You DO want to call the MAX function as infrequently as possible since it will sometimes iterate through a loop.
Ninjatrader's new improved version of MAX, which was suggested to them by RWT, does not do that nearly as often as the old one did. It uses logic tests to avoid unnecessary looping. But it's better to not do even those when a call to MAX is not needed at all.
If you send me your code in a PM, I will review it.
I don't use external indicators in my strategy at all, not even the simplest one like SMA, EMA or ZLEMA
They are all coded as functions.
Strategy is running on 28 currency pairs 6 timeframes
modules(functions): Current OHLC, PreviousDayOHL, RoundNumbers, SwingRays, FibLevels, Pivots, SMA 2 timeframes, EMA 6 timeframes, ZLEMA, CurrencyMeter, New High/Lows
Strategy is running darn fast, and absolutely NO Freezing, NADA
I don't use external indicators in my strategy at all, not even the simplest one like SMA, EMA or ZLEMA
They are all coded as functions.
Strategy is running on 28 currency pairs 6 timeframes
modules(functions): Current OHLC, PreviousDayOHL, RoundNumbers, SwingRays, FibLevels, Pivots, SMA 2 timeframes, EMA 6 timeframes, ZLEMA, CurrencyMeter, New High/Lows
Strategy is running darn fast, and absolutely NO Freezing, NADA
Let me get this totally straight: you write the code into your Strategy for those indicators? Or do you write it into User Defined Functions?
If you write it into your Strategy, don't you have a headache when you have 10 strategies in development and you want to change one indicator that's in all of them?
You can discover what your enemy fears most by observing the means he uses to frighten you.
You should keep your recent highs/low in a queue implemented as arrays, on bar update take out the oldest number, put on the newest number and iterate through them to get the high/low of the lookback period. Anytime you use indexers on DataSeries you are actually calling get() methods/functions on enumerable objects, which involves popping and pushing variables onto the stack, setting up function pointers and contexts, more garbage collection cycles, etc.
double[] arrays sit on the heap because "double" is a value type, not a reference type, and no methods are called to read/write arrays.
Sorry I'm not including sample code, too busy coding other things for other people right now, but maybe someone else can supply something.