
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
Incorrect comparison, as it does not take into account the time for automatic removal of objects.
Modified.
Where 123 megabytes after V3 comes from - I don't know.
Question, how many times in your benchmark is each function run?
Need output of average time, number of runs and stddev.Question, how many times is each function run in your benchmark?
Exactly once.
The combat EA is interested in lag bursts. I haven't done much theoretical experimentation, so I haven't done such a thing.
Vasiliy Sokolov #:
No, correct. And this is a point of principle. Automatic removal does not take place in the main stream, where the time cost is extremely expensive.
Unfortunately, if you measure inside the function and outside, the times are different. Inside is faster. I.e. removing objects has some effect. So the version about the other thread is a bit dubious.
The second point. Pay attention to V2. There is no object deletion and a direct memory leak is purposefully allowed. Even in this case it takes 1.4 seconds versus 1.2 seconds in V1, although there is no time spent on removal at all.
My picture is the opposite.
During the execution of the mql program, no assembler removes anything, neither in the same thread, nor in another thread.
The collector is nominally present, but it is executed only when the module is finished. The messages about leaked memory in the log are just the collector.
Exactly once.
In that case, the benchmark is irrelevant. At least not for me.
It's not about my implementation. You can measure it the old-fashioned way.
So the other stream version is a bit dubious.