Errors, bugs, questions - page 672
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
How many bars are in the window?
The problem is that no memory is being freed up in the terminal when the TF is switched. Start Task Manager, throw the indicator on the chart and watch the memory grow. Then switch to another TF and you will see the memory start to grow again. But logically, when you switch to another TF, the data of the previous TF should be unloaded from memory. Since data from the previous TF are not deleted, memory grows until it reboots and generates an error. If you remove your indicator from the chart, you will see that after a certain period of time the memory is cleared. But it is not cleared while the indicator is running.
My opinion: The solution to this problem is ServiceDec.
Thanks, I will delete the indicator first before switching the TF. In addition I have reduced the max bars in the window from 2000000 to 1000000 apparently MetaDriver wants to tell me that.
So far it seems to be working.
Thanks, I will delete the indicator first before switching the TF. In addition, I reduced the maximum number of bars in the window from 2000000 to 1000000, apparently MetaDriver wants to tell me that.
So far it seems to be working.
Why do you need 100,000? 100,000 is enough for me. That's what I'm trying to tell you.
It does not limit testing to any depth in any way.
It only limits (1) the display in windows (2) the size of the indicator buffers.
I have long and deliberately restricted the "visible history". The result - I have no problems with memory.
Why do you need a million? 100,000 is good enough for me, which is exactly what I was hinting at.
It does not in any way limit testing to any depth.
It only limits (1) the display in the windows (2) the size of the indicator buffers.
I have long and deliberately restricted the "visible history". The result is that I have no problems with memory.
Yes, thanks, I am going to use 108 pairs at InstaForex even more, so I don't have any memory problems.
That's quite a topic. Back in the early days of MT5 I was screaming that all indicators should have a new standard parameter - the number of bars to calculate.
Otherwise we get the only limiter - TERMINAL_MAXBARS. This is not acceptable for Expert Advisors that analyse many symbols in real time using indicators. In most cases (99%) I need in Expert Advisors a strictly specified number of the latest bars AND ALL. Everything else is too much for me. Of course not only me...
It was ignored. As a result, I transferred such calculations to my Expert Advisor's code.
Ah yes! And the appearance of many self-written patches. Some smart articles were even written and published, like the following one:
Decrease the consumption of memory for auxiliary indicators
Implementation of Indicators as Classes by Examples of Zigzag and ATR
...
If you separate the regular displayed indicators and the short calculated indicators, it will be easy to get divergence on the long cumulative indicators.
Also this will lead to dangerous crutches on our side.
A good way is to set 100000 bars per chart or switch to x64.
Renat:
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
In general, nothing changes. The requests for the possibility to limit the size of indicator buffers in MQL5 are rejected, and if your program begins to consume a huge amount of memory because of the many indicator buffers used - then it is called "programming error".
"In Expert Advisors, I most often (99%) need a strictly specific number of last bars AND ALL. All unnecessary things are too much for me. Not only me, of course..." (с)
2) Indicators cannot be counted on a short history, because they are a shared resource shared between all processes (terminal, windows, experts). And there are many rules of updating, synchronization and recalculation of the market environment on indicators.
3. If you separate the regular displayed indicators from the short calculated ones, it will be easy to get divergence on the long cumulative indicators.
Also this will lead to dangerous crutches on our side.
1. a good way is to set 100000 bars per chart or switch to x64.
1. That's what I did. Still, it's an uncomfortable compromise. Ideally, if I take my mind off the development problems completely (purely as a user) I would like to have a choice when setting the length of the calculation. For chart - the full length (though not always, there are serious and big exceptions), for experts - exactly as long as necessary. 3.
2. As a developer, I understand the difficulties and simultaneous limitations of this approach, and yet memory consumption is also my problem, and it stubbornly does not want to fall into the background. I have a concrete suggestion-solution - to consider the calculation period (let's call it so) as an equal parameter-no worse than others. Then two indicators with all similar parameters, but with a different calculation period, are simply two different indicators. Yes, theoretically there are stupid use cases that can lead to additional expenses (if the user will multiply calculation periods), but in practice it's unlikely. If someone wants to go along with this, he/she is guilty. Just like now ALL users are guilty of "having opened too many indicators and did not care to reduce TERMINAL_MAXBARS".
I know that in the EMA calculation all of the bars from the beginning of time are used, but I also know that in stochastics, RSI, and in a huge(predominant) number of other indicators the calculation is performed on an organic length. And this knowledge allows me the flexibility to choose the calculation period (MaxBar). Just give me a choice.
About as much as it is now ALL users' fault for "opening too many indicators and not taking care to reduce TERMINAL_MAXBARS".
Yeah, especially in championship conditions when you can't influence the size of TERMINAL_MAXBARS at all.
1. I have done so. Still, it's an uncomfortable compromise. Ideally, if we take our mind off development issues completely (purely as a user) I would like to have a choice when setting the length of the calculation. For chart - the full length (though not always, there are serious and big exceptions), for experts - exactly as long as necessary. 3.
2. As a developer, I understand the difficulties and simultaneous limitations of this approach, and yet memory consumption is also my problem, and it stubbornly does not want to fall into the background. I have a concrete suggestion-solution - to consider the calculation period (let's call it so) as an equal parameter-no worse than others. Then two indicators with all similar parameters, but with a different calculation period, are simply two different indicators. Yes, theoretically, there are silly variants that can lead to additional expenses (if the user multiplies calculation periods), but in practice it's unlikely. If someone wants to go over this bump - that's his own fault. Just like now ALL users are guilty of "having opened too many indicators and did not care about decreasing TERMINAL_MAXBARS".
I know that in the EMA calculation all of the bars from the beginning of time are used, but I also know that in stochastics, RSI, and a huge(predominant) number of other indicators are calculated on an organic length. And this knowledge allows me the flexibility to choose the calculation period (MaxBar). Just give me a choice.
The message is clear.
We ourselves want to reduce the consumption of resources. Perhaps the solution can be some function IndicatorMaxDepth(uint len) that will act only on indicators created in this EA.
But the problem is that during testing, the buffers of indicators in accumulation mode will grow together with history and there will be no saving. Trimming the indicator's history in real time, while maintaining the specified depth is fraught with beautiful glitches and blow the programmers' minds, who count/used to the synchronism of bars of the chart and indicator buffer.
A better option is to move to x64.
We will revise the cache of indicators, which now uses the principle of maximum efficiency vs. the principle of memory saving. We will try to unload indicators that were rejected immediately, instead of keeping them in memory for some time, as we do now. This will make it possible to call hundreds of indicators in a row with a direct unloading through IndicatorRelease.
Of course, if someone will call hundreds of indicators in the mode of market scanning without unloading them, then they must go straight to the 64-bit version + installation of additional memory.
Now it's strange to be doing massive tests sitting on x32. Any decent x64 computer with 16GB of memory (without being fanatical about graphics cards and monitors) can be bought for 15,000 roubles.