MT5 and speed in action - page 57
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
Acceleration by a factor of ten in cases of massively parallel access.
For other cases only processor, memory and operating system upgrades.
In PM, comparative logs from the same machine.
This is a one time call of CopyTicks. It's done in order to make a virtual backtest for these ticks in OnInit, and then to continue it in real-time, feeding only fresh ticks.
As a compromise, I propose to release the memory in the Terminal immediately after the CopyTicks called in OnInit. Then we don't have to introduce a forced cooling function for CopyTicks.
Right now Sleep-version of cooling is very crutchy. But I showed above how this crutch saves memory.
Now it turns out that 20 Expert Advisors run fast even on slow VPS. But starting them up is a serious problem.
Not so long ago, you yourself have been stress-testing and demanded instant issuing of deep ticks on each tick.
That is, both you and 100% of other developers have applied and will apply pending full cache request strategies. Each time more and more costly and head-on experts are being written.
That's why we won't abolish caches by any means, but recommend to put 16-32gb of memory and forget about problems and delays.
Behavior and economy on VPS (keep to 512 mb-1 gb) we don't care at all.
You yourself were stress-testing not so long ago, and in fact you demanded instant deep ticks on every tick.
That is, both you and 100% of other developers have applied and will apply pending full cache request strategies. Each time more and more costly and head-on experts are being written.
That's why we won't abolish caches by any means, but recommend to put 16-32gb of memory and forget about problems and delays.
Behavior and economy on VPS (to fit in 512 mb-1gb) we don't care at all.
Above supplemented my post with code. It's about OnInit, not something else. Hot CopyTicks is very much needed, but not in OnInit.
As a compromise, I suggest that after CopyTicks called in OnInit, memory should be freed immediately in the Terminal.
Not in any case!
And what if I on the contrary raise cache in OnInit in order to work with it without delays?
It's better to introduce the function to unload the terminal cache.
It is necessary not only for ticks, but also for time series and indicators (try to write a 5K for 5 instruments and 5 TFs).
@Renat?
No way!
What if I raise the cache in OnInit so that I can then work with it without delay?
The tick cache only lives for 10 seconds.
The tick history script screener (the only software running in the Terminal) eats up to 6GB if you take five months' worth of quotations.
The faster the machine and internet, the greater the memory load. I.e. terminal's internal caches accumulate to a few characters in 10 seconds.
I can't think of any other way to know that there is a new tick while OnTick is running.
Three options.
It is better not to identify a new tick through the bars.
Result(inAmount = 15).
Desynchronisation can last up to a minute. There is a bug somewhere.
The reason for SymbolInfoTick's braking seems to be parallel handling.
Result (inAmount = 15).
> 100 ms for SymbolInfoTick execution. It's clear that the code is self-shot. But it shows the reason why slows down on usual EAs.