Can somebody give me a pro's and con's list?
The onTick() method often is my main entry for things to do. For example, one thing is to loop over all pending orders (let's say 20 at a time) and delete them, afterwards open 10 new pending on different price levels. Is it neccessary to block other incoming ticks, until the first function calls to the delete() and create() functions have finished? Here I think about a very fast market, fireing many ticks in small timeframes and calling the delete() function "in parallel", so trying to access orders that are already deleted by the former delete() function call or creating duplicate orders (hedging account). Do things like that happen or are they prevented by the underlying MT5-subsystem?
- My own personal opinion is that the MQL Standard library is "buggy", "bloated" and "slow". I prefer coding my own library code, that works "my way" and as a result, I know how it works under the hood and it is tailored to my way of working/thinking.
- Why delete Pending orders only to recreate them? Just modify them instead! Alternatively, simulate virtual pending orders in your code by using Market Orders instead. This will greatly reduce the Network Overhead and Latency.
- MT5/MQL5 Trade Functions are asynchronous, unlike the synchronous processing in MT4 (please note that I say "functions" as I do not know how the Standard Library implements it).
The onTick() method often is my main entry for things to do. For example, one thing is to loop over all pending orders (let's say 20 at a time) and delete them, afterwards open 10 new pending on different price levels. Is it neccessary to block other incoming ticks, until the first function calls to the delete() and create() functions have finished? Here I think about a very fast market, fireing many ticks in small timeframes and calling the delete() function "in parallel", so trying to access orders that are already deleted by the former delete() function call or creating duplicate orders (hedging account). Do things like that happen or are they prevented by the underlying MT5-subsystem?
Every expert adviser runs in its own thread. While EA is processing current OnTick, it will not be called with another ticks. So you have no need to implement special blocking and synchronization, if only you do not need multiple EAs running in parallel and exchanging some common data. Said that, you should always check orders for existence, because they can be deleted by the server in asynchronous deferred manner.
It has been shown that the standard library imposes some overheads (up to 10%) on overall performance.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hi,
two questions:
in former days I did my work within my small EAs with the "standard" mql5 language, often encapsulated in classes/objects. Now in new projects, I thougth about using the mql5 Standard Library whenever possible (things like opening/closing orders/positions, calculating lot sizes, using and looping over arrays, copy arrays etc. - so to say: standard stuff). Why? To get a little more comfort while coding EAs. But now, from a performance point of view: is there a significant difference in using the Standard Library instead of using the language itself?
Can somebody give me a pro's and con's list?
The onTick() method often is my main entry for things to do. For example, one thing is to loop over all pending orders (let's say 20 at a time) and delete them, afterwards open 10 new pending on different price levels. Is it neccessary to block other incoming ticks, until the first function calls to the delete() and create() functions have finished? Here I think about a very fast market, fireing many ticks in small timeframes and calling the delete() function "in parallel", so trying to access orders that are already deleted by the former delete() function call or creating duplicate orders (hedging account). Do things like that happen or are they prevented by the underlying MT5-subsystem?
Thanks alot & best regards,
Alex