Discussion of article "LifeHack for traders: Fast food made of indicators" - page 5

New comment
 
Vasiliy Sokolov:

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.

 
fxsaber:

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!

 
fxsaber:

As for making the user responsible for shooting unnecessary handles

I see such a topic for the Articles list as logical.

You are laconic as always - please decipher this macro. What topic is meant. You can just give the title for the article.

 
Rashid Umarov:

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".

 
fxsaber:

"The advisability of using IndicatorRelease in Expert Advisors to speed up testing".

And your opinion?

+ How to stretch it into an article
 
Vasiliy Sokolov:

rewriting the indicator to the internal function of the Expert Advisor with parameters.

I wonder what kind of acceleration it would give if implemented correctly....

 
Rashid Umarov:

And your opinion?

+ How to stretch this into an article

There 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

 

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.

 
fxsaber:

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.

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.

 
Renat Fatkhullin:

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.

12345678910111213
New comment