Errors, bugs, questions - page 1850
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
a bug when using a styler?
Let's assume we were writing using the tab.
There's no error.
then we use the styler, we get
i.e., the styler erases the space between theTWO_DIM(10000)
Result
What's the right way?
1. if previously you didn't receive quotes for a ticker at all, didn't open a chart etc. (depends on the ping, internet speed, hard drive, preparation of the file Bases/Broker/history/ticker/cache/)
2. if the quotes have been previously received and then the terminal has been reloaded, provided no chart of this ticker has been opened (preparation of the file Bases/Broker/History/Ticker/Cache/)
time is 10-15 times less than p.1
for comparison the access time in МТ4 according to point 2, i.e. after the terminal reset
i.e. the time after MT4 terminal restart is a few orders of magnitude less.
This time I checked everything on the Windows, without SSD!
When I got the quotes, the terminal was not rebooted, the data was accessed
Did I get it right that after loading the cache, the terminal needs considerably less time for further requests (starting from the 2nd request)?
Can we somehow reduce the time for the first call after the terminal restart to make it like in MT4?
The code was in https://www.mql5.com/ru/forum/1111/page1870#comment_4856899
You have a very dirty test method as there is no environment and playback method description at all.
Not specified:
Without this the conclusions are unfounded.
For example look at EURUSD M1 - MT5 has more than 6 million bars there (if unlimited mode at charts), but MT4 has how many? A couple of tens of thousands of M1 bars in the actual database?
You have a very messy test method as there are no descriptions of the environment and playback method at all.
Not specified:
limits of bars in the window
Without that the conclusions are unfounded.
I have been asked most of the questions in my post, no problem, I'll give you all the data now.
first of all the answer to the
MQ-demo server, the data is loaded, as we are talking about point 2 and point 3 in the previous post. With point 1 everything is clear and there are no questions there - as it was written - data is loaded, cache is formed on the specified path.
MT4
MT5
MT4
MT5
win XP 32bit, all builds of MT all latest
MT4 - open 1 chart, check with another symbol
MT5 - 1 chart opened, check with another symbol
repeat, reload the terminal, send the script to the chart, select OTHER symbol, data on which has been loaded BEFORE reloading the terminal
MT4
MT5
Here's my test with more detail and more accuracy:
Test files are attached and all times are in microseconds (not milliseconds, 1 millisecond = 1000 microseconds).
Now the conclusions:
No problem here - lifting always costs resources.
Especially when conceptually different architectures are used: MT5 has more complex caches (cache\*.hc files are built from original *.hcc) for the sake of scaling + mandatory full synchronization control with server data (binary *.hcc chunks).
There are no failures in both terminal implementations and everything works fast.
Thank you for your reply.
Overall, the results are as I showed in my posts.
I have been testing on a regular one.
And yet the results between MT4 and MT5 are almost 200 times different (due to -must control full synchronization with server data?? and ping? ).
I kind of got used to it before posting here that it's probably a feature of the terminal. I can even live with it, but it is difficult at some points. For example, as there's no market-screener in MT, I wrote a little script, which adds symbols to market watch, but the prices are only available via CopyClose, they are not available via SymbolInfoDouble or via MqlTick until the symbol is added to the watch, so this script runs "infinitely" long when run with a very large stake. This is just an example.