![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
Data Part :
- I need to poll market characteristics for instance price behavior on sessions, speed activity, breakout, etc -- It's not effecient to do that with buffers right ?
so, It's logical to use FileWrite functions ( or not? ) and keep data in txt or csv files.
Depends on many factors... If this data needs to be stored for later use then obviously use a file. If this data needs to be referenced all the time then keeping it in memory would be faster, but if it's too big it will take a lot of it. Then u might need to store this data to file once in a while for persistence. So it depends on the specific data and usage.
Function Part :
- In my mind, EA can call hundreds of functions. It's not efficient to keep this in EA; so function modules should be used.
which is more efficient ?
Native MQL4 code (in main file or in an 'include' file) would *usually* be faster than a library or a DLL (but not necessarily).
- I will do some research, but if you would indulge me : When or where does DLL comes to play ?
Here's an excellent explanation by jjc -> https://www.mql5.com/en/forum/119371
Depends on many factors... If this data needs to be stored for later use then obviously use a file. If this data needs to be referenced all the time then keeping it in memory would be faster, but if it's too big it will take a lot of it. Then u might need to store this data to file once in a while for persistence. So it depends on the specific data and usage.
Native MQL4 code (in main file or in an 'include' file) would *usually* be faster than a library or a DLL (but not necessarily).
Here's an excellent explanation by jjc -> https://www.mql5.com/en/forum/119371
Here's an excellent explanation by jjc -> https://www.mql5.com/en/forum/119371
Thanks...
Native MQL4 code (in main file or in an 'include' file) would *usually* be faster than a library or a DLL (but not necessarily).
That's very debatable, and depends on practical considerations. For example, taking something which is purely processor-intensive such as fbj's hash code from https://www.mql5.com/en/forum/120034/page2, then MT4 runs the iMakeHash() function about 50 times more slowly than a compiled C version of the same function. (It would be odd if interpreted MQL4 p-code were beating compiled code.)
However, in practice, there's an overhead in calling DLL functions from MQL4, and there is often an overhead in having to assemble data to give to the DLL - e.g. copying close prices into a custom array so that they can be handed over to the DLL for calculations. You've got to be doing something pretty heavyweight such as neural net calculations before it's worth shifting code out into a DLL on speed grounds.
And, while MQL4 may not be particularly fast in the grand scheme of things, it's usually far, bar better than fast-enough.
That's very debatable, and depends on practical considerations. For example, taking something which is purely processor-intensive such as fbj's hash code from https://www.mql5.com/en/forum/120034/page2, then MT4 runs the iMakeHash() function about 50 times more slowly than a compiled C version of the same function. (It would be odd if interpreted MQL4 p-code were beating compiled code.)
However, in practice, there's an overhead in calling DLL functions from MQL4, and there is often an overhead in having to assemble data to give to the DLL - e.g. copying close prices into a custom array so that they can be handed over to the DLL for calculations. You've got to be doing something pretty heavyweight such as neural net calculations before it's worth shifting code out into a DLL on speed grounds.
And, while MQL4 may not be particularly fast in the grand scheme of things, it's usually far, bar better than fast-enough.
No debate this time. I pretty much agree with everything u said. What I meant was - 'in practice' it's usually faster.