MQL5 bug when working with iClose/iOpen timeseries access, etc. - page 7
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
1) Measure execution time per OnTick/OnCalculate calculation in microseconds and display them in the log.
That way you can see how long it takes you to calculate one tick. Then estimate how many ticks at this speed you can count per second. It will probably turn out to be no more than a dozen ticks, and there are knowingly more ticks per second.
2) Measure the time for each OnCalculate on the indicators which are attached to the charts/timeframes you are extracting data from.
There's probably a similar situation there. Due to slow calculations, the terminal waits until the calculated symbol:timeframe is unlocked. It is the slow indicators, especially on a deep history, that leads to freezing of other traders' charts.
When designing indicators you need to put performance issues and economical recalculations first. Otherwise you will kill everything around you.
Renat, it's really quite sad. Are tiki now waiting for me to sort out my problems? Until now, I assumed that tics were self-generated, and I either have time or I don't. Now it turns out that I can suspend the system.
Renate, it's been quite sad. Are the tics now waiting for me to sort out my problems? Until now, I assumed that the tics were generating themselves, and I either have time or I don't. Now it turns out that I can hang the system.
The indicator runs on every tick, with no skips. You have to monitor the OnCalculate duration and the frequency of ticks coming in all the time. Otherwise you will get a jam.
The easiest way to reproduce it is to run the indicator on a custom symbol and start ticking it with a certain frequency. As the frequency increases, you'll see braking. It's all logical.
In what cases can the indicator not draw its value? buffers are filled with valid values, but the indicator's chart is empty.... at least it's not vice versa. build 1940
1944 the same. it must be so.
The indicator is executed on every tick, with no skips. You need to monitor OnCalculate duration and tick arrival rate all the time. Otherwise you will get a jam.
The easiest way to reproduce it is to run the indicator on a custom symbol and start ticking in it with a certain frequency. As the frequency increases, you'll see braking. It all makes sense.
Yes, exactly like that.
Renate, it's been quite sad. Are the tics now waiting for me to sort out my problems? Until now, I assumed that the tics were generating themselves, and I either have time or I don't. Now it turns out I can hang the system.
The ticks have always been waiting. We guarantee to call OnCalculate on every tick.
Whereas in fours it caused the GUI to freeze, in fives it's just a delay in an individual thread processing a particular character. And it was always like that in five. It's just that you've only seen it now
Frozen update of alien invisible timeframe after reconnect was solved and fixed. The reason was in wrong cache statuses after the reconnect.
Beta Version 1946 available via Help -> Check Desktop Updates -> Latest Beta Version.
Updated, let's test it.
The question is whether the current problem was also related to cases of loading other tools (invisible timeframe), I mean multicurrency indicators and EAs or these are not interrelated problems?
The ticks have always been waiting. We guarantee to call OnCalculate on every tick.
If in fourth, it would freeze GUI, but in fifth, it is just a delay of a separate thread processing a particular character. And it was always like that in fifth. It's just that you've seen it only now.
the terminal log will have a message about this situation, something like "indicator is too slow" ?
?
will there be a message in the terminal log about this situation, such as "indicator is too slow"?
?
In the Expert log
Thank you, that's something, but I understand that it cannot be programmatically determined that the indicator calculates ticks that are not relevant and the indicator hangs the terminal thread?
Thank you, that's something, but I understand that you cannot programmatically determine that the indicator is calculating ticks that are not relevant and the indicator is suspending the terminal thread?
It is possible to try to determine.
If it is minutes, you can compare the time of the last bar with TimeCurrent(). If it is not M1, you can ask iTime(_Symbol,PERIOD_M1,0) and compare with TimeCurrent().
You can compare the Bid or Last price (depending on the symbol) with the Close price of the last bar. You can directly ask SymbolInfoTick for the current symbol. In addition to the Bid and Last, there is also the tick time