
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
Adding an order/trade to the trading history causes the HistorySelect cache to be rebuilt completely, not partially. Hence the lags in triggering of pending orders.
b2595 - corrected, Great!
Checked on the wrong story, haven't fixed it yet.
Forum on trading, automated trading systems and trading strategy testing
MT5 and Speed in Action
fxsaber, 2020.09.08 19:46
b2596 has become faster, it seems.
Can you tell me what to do to avoid this kind of thing when trading?
The last line is normal.
Can lags be affected by EAs running in parallel? No indicators.
SZY Profiling on empty terminal.
SymbolInfoTick is an expensive function.
Can lags be affected by EAs running in parallel? There are no indicators.
I have launched an empty terminal in parallel and tried it. I have not seen the same thing.
Configuration.Forum on trading, automated trading systems and strategy testing
MT5 and Speed in Action
fxsaber, 2020.09.01 21:59
Installed Win10, LatencyMon shows everything is fine.
Anyway, due to the fact that almost every regular function can cause a slowdown, the battle Expert Advisor performs every OnTick for several tens of milliseconds. The sum of calls Order*+SymbolInfoTick+Position*, etc. eats that much. There are no mathematical calculations. You need free snapshots. Without them, HDI on MT5 does not work.
Something is wrong with the approach... Apparently, OnTrade functions are needed rather than scanning the state from scratch on every tick.
Something is wrong with the approach... Apparently, OnTrade functions are needed, rather than scanning the state from scratch on every tick.
The OOP paradigm assumes that each sub-TC scans the trading environment. However, if you really want to, you can break the independence of OOP objects a bit.
For example, make a full-fledged snapshot at the very beginning of OnTick. And it must be repeated only after the call of synchronous functions - OrderSend and CopyTicks.
As for OnTrade*, connection breaks screw up the scheme when snapshots are done only in OnTrade-functions. Otherwise, of course, there would be a big saving.
The OOP paradigm assumes that each sub-OS scans the trading environment. However, if one really wants to, one can break the independence of OOP objects a bit.
For example, make a full-fledged snapshot at the very beginning of OnTick. And it will be repeated only after the call of synchronous functions - OrderSend and CopyTicks.
Of course, the snapshot object must be one.
As for OnTrade*, link breaks screw up the scheme when snapshots are done only in OnTrade functions. Otherwise, of course, there would be a big saving.
Detect a connection break and force update the snapshot on the next tick, then go back to economy mode?