Errors, bugs, questions - page 2776
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
This is not an error, it is the cost of a sync command to a chart
Why do you need a command to a chart to take characteristics off of it? Isn't there just a table of characteristics of all the charts in memory, from which you can simply take data in nanoseconds instead of milliseconds (not even microseconds!)
It is clear that ChartSetInteger, ChartSetDouble, ChartSetString functions are asynchronous.
But why do ChartGetInteger, ChartGetDouble, ChartGetString functions behave as asynchronous in terms of execution speed when they are synchronous?
If such table doesn't exist in memory and these functions need to slow down the chart every time for it to generate the requested parameter, then I don't understand anything.
It's not expensive to have such a table and keep it up to date. Realistically a few kilobytes in memory and a small fraction of a microsecond to update the table when the characteristics of the chart change.
Ilyas, please tell me, what am I missing?
But why then ChartGetInteger, ChartGetDouble, ChartGetString functions behave asynchronous in terms of execution speed, when they are synchronous?
You have some kind of incorrect understanding of the terms asynchronous and synchronous.
When they say that a function is asynchronous, it means that it will be executed not in the current thread of execution but in some other thread - parallel.
The function is asynchronous - it means that the function does not wait for the execution of the command successfully queued in the specified chart but immediately returns control.
The property will change only after the command has been processed in the chart queue. TheChartRedrawfunction must be called to immediately execute commands in the chart queue.
Calling asynchronous as ChartSetInteger function from the main thread is fast as the actual execution takes place in another thread.
On the other hand, calling the ChartGetInteger synchronous function will require synchronization of threads and this may require additional time.
The delays are especially noticeable when the parallel thread is constantly updating the chart structure data (for example, when the user moves the chart window or scrolls through the history).
Most likely, for simplicity and reliability, a single synchronization object is used for its chart data structure.
You can try to improve the speed of execution using "data segmentation", but on the other hand now you can run into deadlocks, or under-updated data, or slowdowns in other more critical areas.
In general, it is better not to touch something which is already running smoothly.
You have some misunderstanding of the terms asynchronous and synchronous.
When you say that a function is asynchronous, it means that it will be executed not in the current thread of execution, but in some other thread.
Calling an asynchronous as ChartSetInteger function from the main thread is fast as the actual execution occurs in a different thread.
On the other hand, a call of a ChartGetInteger synchronous function will require synchronization of threads and this may require additional time.
The delay is especially noticeable when the parallel thread is constantly updating the chart structure's data (for example, when the user moves the chart window or scrolls through the history).
Most likely, for simplicity and reliability, one synchronization object is used for its chart data structure.
You can try to improve the speed of execution using "data segmentation", but on the other hand now you can run into deadlocks, or under-updated data, or slowdowns in other more critical places.
All in all, it's better not to touch something that's already running stably.
Your right, but there seem to be some bottlenecks. The market is now closed, I've run the code below on 1 chart, nothing else works. It's running on a VPS with only MT5 running and I haven't interacted with chart / MT5 with anything other than a screenshot. Time in µs, 127 µs on average, but the peak is 43,995 µs.
Gentlemen developers!
Please correct me if I have written in the wrong thread. There are suggestions for ease of use and debugging, which I think will be useful for many, and for me are important.
1. Increase the length of OBJPROP_TOOLTIP line for objects (2 times is enough). For strategies with a lot of graphics, the current length is very short. For debugging, you have to spend time each time to fit all the necessary data in. Then you have to change and/or add reductions for consumers on a regular basis.
2. Increase the length of comments to the names of input parameters (2 times is enough). Comments to input parameters are necessary for consumer. And if there is a large number, it is also convenient to make additional numbering. For optimization, it is important to know the name of the variable. As a result, it is often not possible to fit everything into the current length. Example:
3. To vary the selection of columns in the optimization results table up to displaying everything fromENUM_STATISTICS and let the user choose what he/she needs. This is avery poor choice for analysis. The drawdown in % is useless during optimization with a fixed volume. There is no possibility to choose the maximum drawdown in terms of currency and deposit. Sometimes there is a strong bias between buy and sell positions during optimization, but you can learn about it only after running a single test. We often have to enter the missing parameters into the result field(STAT_CUSTOM_ONTESTER). But we want to display additional result criteria there, and it's possible to display only one, which we could still put up with, if we had varied the number of columns of standard criteria fromENUM_STATISTICS. All in all, I have to spend a lot of extra time on over-optimisation and analysis.
Thank you!
Your right, but there seems to be some bottlenecks. The market is now closed, I ran the below code on 1 chart, nothing else works. It's running on a VPS with only MT5 running, and I haven't interacted with the chart / MT5 with anything other than a screenshot. The timing is in µs, 127 µs on average, but the peak is 43,995 µs.
I'll assume the peak is the rendering of the chart comment, otherwise, when the chart queue is empty, the ChartGetXXX function call (note the call with synchronisation) takes 0.13 milliseconds
You have some misunderstanding of the terms asynchronous and synchronous.
When you say that a function is asynchronous, it means that it will be executed not in the current thread of execution, but in some other thread.
Calling an asynchronous as ChartSetInteger function from the main thread is fast as the actual execution occurs in a different thread.
On the other hand, a call of a ChartGetInteger synchronous function will require synchronization of threads and this may require additional time.
The delay is especially noticeable when the parallel thread is constantly updating the chart structure's data (for example, when the user moves the chart window or scrolls through the history).
Most likely, for simplicity and reliability, one synchronization object is used for its chart data structure.
You can try to improve the speed of execution using "data segmentation", but on the other hand now you can run into deadlocks, or under-updated data, or slowdowns in other more critical places.
In general, it is better not to touch something which is already running smoothly.
If you press the PrtScr button and move the chart window around, it causes horrible delays of up to 5 seconds.
However, if you only take a screenshot of the terminal.exe program window with ALT + PrtScr, there is no delay at all.
Judging by the built-in VPS service, there is some experience.
I will assume that the peak is the rendering of the chart comment, otherwise, when the chart queue is empty, the call to the ChartGetXXX function (note, the call with synchronisation) takes 0.13 milliseconds
No, Ilyas, it looks like no chart comment. I'll use the logs and post it.
Edit: Here is the result, no interaction with the chart or MT5 or Windows, after running it, except to copy the logs. Only 1 chart, no other software running on the system. Peak is less, but still very important compared to average. (µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Number = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
No, Ilyas, looks like no comment on the graph. I will use the logs and post it.
Edit: Here is the result, no interaction with the chart or MT5 or Windows, once started, except to copy the logs. Only 1 chart, no other software running on the system. Peak is less, but still very important compared to average. (µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Number = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
Update :
Maximum peak now seriously increased:
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Max = 23520
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Min = 33
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Max = 81011
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Avg = 149