![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Would a realtime kernel help in any way?
Put in more cores and don't push the situation to 100% single core load.
Don't believe in fairy tales, processors and thread scheduler don't work the way you imagine.
In the latest builds the tick stream reception has no effect even theoretically. Practically SymbolInfoTick already works with cache, but individual citizens keep looking for a black cat.
And it's not even 80% in the test. It has 6 agents running on 4 cores, i.e. 100% guaranteed.
The only question is how his system's task scheduler is handling the situation. At the same time, some claims are being made that it is the terminal implementation which is to blame.
That is, a situation is artificially created when a computer is overloaded, when literally everything on it slows down, and then some claims are made in the form of "Oh, look, why is the terminal lags sometimes".
Let's close our eyes to the fact that even in such conditions it is "about 0.01%" - to hell with the details! Suffice it to say that "no one cares about the average hospital temperature", "lags cause problems when trading" and "we want HFT".
Moreover, of course we want HFT in 20 experts on an old office desktop or a dead virtual machine.
PS PositionSelectByTicket() in its implementation certainly has access to a shared resource with access synchronisation. And if you don't select the position on every call, you're reading the old price. It was easier to do a "snapshot" via SymbolInfoDouble.
thanks
I got my question because six months ago, I was optimizing my code and testing the speed of system functions, and six months ago, SymbolInfoDouble was slower than SymbolInfoTick
Overall, I think you're right. Just googled few articles today about multi-core cache (I haven't got interested in this info for a long time),
here's a short articlehttps://i2hard.ru/publications/25666/
the point is that data gets to run in ALU only from L1-cache which is very small and if you load processor full speed, then really - the test will turn into a test of the operating system + test of the processor cache speed (loading, predicting L1+L3 data) but not in testing code (application) performance
fxsaber, what if you set a low priority for agents in task manager and a high one for MT5?
I can't find a utility that would block all programs/OS threads from being allocated to a specific CPU thread, otherwise it would be possible for MT5 to reserve a thread and automatically block it from being used by other programs, which could in theory reduce lags.
In the latest builds the tick stream reception has no effect even theoretically. Practically, SymbolInfoTick already works with cache, but certain citizens keep looking for a black cat.
A particular citizen has got the MQL-codeduplicated from his wide trousers which showed that the crutch works faster than the regular function under the same conditions.
But you argue that your function is good, it just has limitations on conditions of use.
And it's not even 80% in the test. There are 6 agents running on 4 cores, i.e. 100% guaranteed.
The only question is how his system's task scheduler is handling the situation. At the same time, the authors make claims that it is the implementation of the terminal that is to blame.
That is, a situation is artificially created when a computer is overloaded to its limits and everything slows down on it, and then some claims are made in the form of "Oh, look, why is the terminal lags sometimes".
6/8 - nothing is lagging. Browsers, compilation, debugging etc. run in parallel without any hint of lags.
But now I've purposely turned everything off, leaving only 4/8 Agent. The situation has not changed with your function braking.
What's more, of course, we want HFT in 20 experts on an old office desktop or a dead virtual machine.
A fast machine was used. And only 6 charts were already giving the brakes.
PS PositionSelectByTicket() in its implementation certainly has access to a shared resource with access synchronisation. And if you don't select the position on each call, you read the old price. It was easier to "snapshot" via SymbolInfoDouble.
I use this too.
What kind of speed in combat performance can we talk about when there are problems in the terminal.
The Expert Advisor scans all financial instruments and searches for a given pattern.
It stumbles on a symbol and hangs tight!!!
Code from help, I put only steps, financial instrument with problem and timer:
Result of the work:
I never waited for the script to finish running.
As long as the terminal has such bugs, no battle execution is out of the question!!!
It was expected that when a security gets into the market review, at least all of its properties and the start date of the history are pulled up for it. If there is no history on the server, then
SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date)
Should return NULL instantly, why the execution time 18446744073475877138 ?
Maybe i don't know something, CopyXXX function also hangs for 16-29 seconds !!!
It's not normal for a broker to have 3000-6000 financial instruments.
Maybe I don't know what, the CopyXXX functions also hang for 16-29 seconds!!!
It's not normal for a broker to have 3000-6000 financial instruments.
Bars are evil. So please post about them in another thread.
Bars are evil. So please post about them in another thread.
Maybe you know how to programmatically select a financial instrument and not get hung up for ages?
Maybe you know how to programmatically select a financial instrument and not get hung up for ages?
I haven't come across such a task.
fxsaber, what if you set a low priority for agents in task manager and a high one for MT5?
I can't find a utility that would block allocation of a specific CPU thread to all programs/OS threads, otherwise it would be possible to reserve a thread for MT5 and automatically block its occupation by other programs, which could in theory reduce lags.
Set all Agents to lowest priority.
It does not work.
ZZZ The number of EAs running affects the result.
Dear developers, could you please inform me how MQL_MEMORY_USED is calculated?
I have calculated the memory that all EA's variables are taking up.
It is less than 10%. If I understand correctly, MQL_MEMORY_USED includes the History cache and CopyTicks cache. But it is still much less.
At the same time, the parallel Expert Advisor consumes several times less. But the principle is the same.
In general, what is included to this value?
I have saved a template with Expert Advisor and applied it to the same chart by causing reloading. I have seen it like this.
The memory usage has changed by almost an order of magnitude. It's hard to explain what this means at the moment.