That is, there is still an overhead, and not a small one at that. Vladimir's example is more trustworthy, because the call was used in the real work of the EA.
However, enough with the confusion! It seems that we need to look at it in detail. But there may be purely technical interest here, as there can be no practical interest.
However, enough with the confusion! Looks like you need to look at it in detail yourself. But there may be purely technical interest here, as there can be no practical interest.
Yes, I myself am already confused completely:) If you make us a normal analysis of the situation - it will be great!
In fact, the description of this topic is a bit different:
Thousands of indicators have already been written, accessed via iCustom with allocation of appropriate buffers/handles and so on and so forth. This is a slow and resource-intensive story;
An indicator can be implemented as a pure function inside an Expert Advisor - in this case the required value will be calculated much faster and will require less memory.
The idea is to write some kind of interface that would allow unified access to any custom indicators, but if the indicator is implemented as a separate pure function, the reference is made to this function instead of the handle. As a result, we get a good acceleration and at the same time we do not lose access to any arbitrary indicator. This is an interesting topic, I would even take it up.
Yes, it is a frontal method, which fully justified itself, as it was required for accuracy and did not need any performance at all. The task was to close the interfering cleverness of MT5.
And others, of course, did not try, because.
As for taking on the user the task of shooting unnecessary handles.
I see such a topic for the Articles list as logical.
There is no automatic shooting of indicator handles during MQL5 application operation. Indicator handles are automatically released only after the MQL5 programme is finished within the framework of "cleaning up after a sloppy programmer". We should explicitly write vornings in such cases to raise the quality of programmes.
Therefore, the one who creates a bunch of indicators and does not control their removal creates big problems. Both for his programme and for the whole terminal.
I repeat once again - the methods of work in the article are categorically harmful and incorrect.
There is no automatic targeting of indicator handles during MQL5 application operation. Indicator handles are automatically released only after the MQL5 programme is finished as part of "clean up after a sloppy programmer".
Therefore, the one who creates a lot of indicators and does not control their deletion creates big problems. Both for his programme and for the whole terminal.
Well, then for these Expert Advisors.
computational resources and memory to carry the baggage of a hundred handles through a hundred bars. But I haven't seen EAs in the same kodobase that would nail a handle like this. Everything is given to the "cleverness of MQL5", thus forcing the authors to be not clever at all.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
That is, there is still an overhead, and not a small one at that. Vladimir's example is more trustworthy, because the call was used in the real work of the EA.
However, enough with the confusion! It seems that we need to look at it in detail. But there may be purely technical interest here, as there can be no practical interest.
However, enough with the confusion! Looks like you need to look at it in detail yourself. But there may be purely technical interest here, as there can be no practical interest.
Yes, I myself am already confused completely:) If you make us a normal analysis of the situation - it will be great!
As for making the user responsible for shooting unnecessary handles
You are laconic as always - please decipher this macro. What topic is meant. You can just give the title for the article.
You're as succinct as ever - decipher this macro, please. What topic is meant. You can give me a title for an article.
"Expediency of using IndicatorRelease in Expert Advisors to speed up testing".
"The advisability of using IndicatorRelease in Expert Advisors to speed up testing".
And your opinion?
+ How to stretch it into an articlerewriting the indicator to the internal function of the Expert Advisor with parameters.
I wonder what kind of acceleration it would give if implemented correctly....
And your opinion?
+ How to stretch this into an articleThere should be a reasoned classification of EAs where IndicatorRelease speeds up testing significantly and saves time/money. And where it does not?
And add this
Forum on trading, automated trading systems and testing trading strategies
Discussion of the article "LifeHack for trader: cooking fast food from indicators"
Vasiliy Sokolov, 2018.01.26 09:30 AM
Rewriting the indicator to the internal function of the Expert Advisor with parameters.
In fact, the description of this topic is a bit different:
The idea is to write some kind of interface that would allow unified access to any custom indicators, but if the indicator is implemented as a separate pure function, the reference is made to this function instead of the handle. As a result, we get a good acceleration and at the same time we do not lose access to any arbitrary indicator. This is an interesting topic, I would even take it up.
I wanted objective conclusions.
Yes, it is a frontal method, which fully justified itself, as it was required for accuracy and did not need any performance at all. The task was to close the interfering cleverness of MT5.
And others, of course, did not try, because.
As for taking on the user the task of shooting unnecessary handles.
There is no automatic shooting of indicator handles during MQL5 application operation. Indicator handles are automatically released only after the MQL5 programme is finished within the framework of "cleaning up after a sloppy programmer". We should explicitly write vornings in such cases to raise the quality of programmes.
Therefore, the one who creates a bunch of indicators and does not control their removal creates big problems. Both for his programme and for the whole terminal.
I repeat once again - the methods of work in the article are categorically harmful and incorrect.
There is no automatic targeting of indicator handles during MQL5 application operation. Indicator handles are automatically released only after the MQL5 programme is finished as part of "clean up after a sloppy programmer".
Therefore, the one who creates a lot of indicators and does not control their deletion creates big problems. Both for his programme and for the whole terminal.
Well, then for these Expert Advisors.
computational resources and memory to carry the baggage of a hundred handles through a hundred bars. But I haven't seen EAs in the same kodobase that would nail a handle like this. Everything is given to the "cleverness of MQL5", thus forcing the authors to be not clever at all.
It's a complete ambush.