MT5 and speed in action - page 25
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
Naturally, no experts/indicators/scripts are running - only manual builds. The latency indicated is reproducible on any average modern 64-bit tablet. If you have an i7 computer, I don't think you've encountered this delay
is the apk or the exe-system slowing down?
On the other Terminal, Optimisation is running in parallel on six local Agents out of a possible eight.
If these are network breaks, why does it affect getting the last tick from the Market Watch and getting the last tick from the tick history?
ZZY The Terminal log is on the same stretch.
If these are network breaks, why does it affect getting the last tick from the Market Watch and getting the last tick from the tick history?
Careful analysis has shown that CopyTicks is slowing down when there are network breaks.
First of all, FYI.
"If thebasic structure check (pointer check) is successful, true is returned -it does not indicate successful execution of the trade operation. To get a more detailed description of the result of the function execution, the fields of theresultstructure should be analysed."
Secondly, according to your logic, if an order is opened, you don't add it to the list of orders, but completely invalidate the cache)?
You can THAT optimize all code, that you have HistorySelect will be the last place for questions on execution time) Use caching. You can invalidate it, for example, once a day, but it will significantly speed up your EA.
Well, first of all
You either have to run the code to understand it correctly, or read it very well from a worksheet.
Secondly, according to your logic, if an order is opened, you don't add it to the list of orders, but invalidate the cache entirely)?
The order list does not change. Read the code.
to understand the code correctly, you either have to run it or read it very well from the sheet.
The list of orders does not change. Read the code.
Here
I see this logic:
But it can be that the request is already rejected on the server - there is no check for this in this code. What is the point of selecting the history? What do we want to see there?
Here, in these two lines of code, I personally don't see the point. I would see it if there was a check to change the story before selecting it. Maybe, of course, these two lines don't give you a complete picture of the task. But the connection between successfully sending a request to the server and selecting the entire history is not clear to me. Even if the server successfully sends a request, the list of market orders and positions will be changed. What does the history list have to do with it?
Here's where
I see this logic:
But it could be that the request was already rejected on the server - there is no check for this in this code. What is the point of selecting the history? What do we want to see there?
Here, in these two lines of code, I personally don't see the point. I would see it if there was a check to change the story before selecting it. Maybe, of course, these two lines don't give you a complete picture of the task. But the connection between successfully sending a request to the server and selecting the entire history is not clear to me. Even if the server successfully sends a request, the list of market orders and positions will be changed. What does this have to do with the history list?
If - to get rid of the compiler warning. It has nothing else to do.
This thread is not for teaching you how to write EAs. It is intended to eliminate the weaknesses of the Terminal. Developers need a simple, concise and reproducible code to understand it. I don't write anything of this kind for myself, of course. The fact is, the Combat Advisor logs the brakes. I start digging and realize that the slowdown occurs when someone (at least by hand) modifies a position. This resets the historical cache, although the history doesn't change, of course.
The code demonstrates the problem perfectly. There's never a need to clutter up the replay code with any unnecessary checks. Its job is to clearly show the problem. And when fixed - to prove that everything works correctly now.
to understand the code correctly, you either have to run it or read it very well from the sheet.
The list of orders does not change. Read the code.
Consider that I am very good at reading from the sheet :)
This code you took from somewhere else and you have there a new position creation, which is executed, right?
Otherwise the whole point of your code boils down to updating TP of the current position and invalidating the cache for the sake of it, which is also very strange.
In either of those two cases no logic is used to optimise the caching operation. In addition, your solution is not scalable, as it leads to increased braking as the history grows.
The code perfectly demonstrates the problem. There is never any need to clutter up the replay code with any unnecessary checks. Its job is to clearly show the problem. And when corrected - to prove that everything works correctly now.
So by your logic, this code here
demonstrates processor sluggishness?
You got this code from somewhere and you have it there by creating a new position, which does get executed, right?
So, according to your logic, this code here
shows processor slowness?