iConfused with iCustom!!!

[SteveHopwood]

On a separate note, I read somewhere that iCustom had been improved in one of the recent build changes and it is now much faster. I can't find the post ( ) but the general gist was that the calls have been improved by only initialising the indicator once and keeping it open in memory with all the buffers populated so that it doesn't recalculate historic bars on each new call. Of course that's all great if it actually works!....

Yes, that is true. An EA will load and cache in memory an instance of the indicator for each unique combination of its input parameters, as specified in the iCustom call. This can be demonstrated by the attached TestEA and TestIndicator: In the OnInit of TestIndicator there is a print statement telling us that it is being initialized. The TestEA loads TestIndicator with three different sets of input parameters: therefore Empty4 loads three different instances of the indicator and keeps them cached in memory -- resulting in only three print statements.

Thanks Bruce for bringing this up and Rene for confirming it.

It will not stop me being rude about Crap Custom Abortions (not an epithet applied to the excellent indicators coded by the fantastic coders here), but it does mean I do not have to worry about cpu's emitting blue smoke any more.

[Bruster400]

Yes, that is true. An EA will load and cache in memory an instance of the indicator for each unique combination of its input parameters, as specified in the iCustom call.

Thanks for confirming this Rene. If we know that each successive iCustom call does not re-initialize the indicator, can we also assume that the call is taking into account any control over the indexing limit in the "for" statement? - such as:

Code: Select all

limit = rates_total-prev_calculated;

ie. does each call calculate using just new bars or all bars? If it's all of them then iCustom is still flawed but if it is just looking at new bars then it might actually be faster than an internal function (at least the very basic ones I write!! )

Not asking for anyone to spend time on this but just wondered if anyone already knows this.

Thanks

Bruster

[renexxxx]

If it's all of them then iCustom is still flawed but if it is just looking at new bars then it might actually be faster than an internal function (at least the very basic ones I write!! )

Of course you are supposed to write your internal function to be as efficient as possible, so only recalculate the last bar if nothing else has changed (like you do in the indicator). We are talking here about the overhead of the iCustom-call itself, and the fact that Empty4 creates a new instance of the indicator for all combinations of input parameters. Suppose you have a multi-symbol, multi-timeframe EA, that calls iCustom for 28 pairs on 4 timeframes with 3 different parameters: Empty4 will then load and cache 28x4x3 instances of the indicator. You will see the memory footprint of the terminal.exe process increase dramatically. Compare for instance the HGI-indicator based version of HGIMatrix to the HGI-library based version and you will see what we mean.