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
Even so, the top code sometimes wins, but very rarely, i.e. the link is free
) well that's not how it works)
That's how it works in C++
I think it's the same in mql but with additional wrappers from MQ
Forum on trading, automated trading systems & strategy testing
FAQ from Beginners MQL5 MT5 MetaTrader 5
Roman, 2019.12.11 14:02
You don't have to think it through, why should I... The compiler will do it all by itself. ))
C# is not C
Take a look at the video about __inline.
It explains there how functions work in memory for those who don't make any difference.
This is how it works in C++
In mql I think the same, but with additional wrappers from MQ
Well, now reread this thread and a lot of statements and test examples - that there is some difference. And we found it)))
Well now reread this thread and a bunch of statements and examples of tests - that there is a difference. And they did))))
No )) I have no desire to reread it.
It's obvious to me that there is a difference.
No )) I have no desire to reread it.
It's obvious to me that there is a difference.
)))) another IMHO.
The upper way is faster by almost 15% this is very significant, well if everything is so obvious explain it to me)
)))) another IMHO
Top way is faster by almost 20%, well since everything is so obvious explain it to me)
The loops being compared are not the same in terms of code in the body.
The first loop has one code in the body, the second loop's body has another code.
Naturally different code instructions, naturally different execution time.
Make the same code in the loop body and change only the loop condition ArraySize and the size variable.
We are testing this part, not the body.
The loops being compared are not the same code in the body.
The first loop has one code in its body and the second loop's body has another code.
Naturally, different code instructions and execution time are different.
Make the same code in the loop body and change only the loop condition ArraySize and the size variable.
We are testing this part, not the body.
Your test is more incorrect because it depends on the launch case, run it again. Here in both cases there is an increment and one division. Well, plus there are a couple of extra tens~ billions of ArraySize calls on top.
By the way, it's in the body that we should write what we're testing. Because it's the body that gets repeated. We are trying to wrap it into loop.... to get the result i.e. it was originally necessary tocall ArraySize from the body
Your test is more incorrect as it depends on the launch case, run it again. Here both cases have increment and one division. Well, plus there are a couple of tens~ billions of ArraySize calls on top of it.
By the way, it's in the body that we should write what we're testing. Because it's the body that gets repeated. We are trying to wrap it into loop.... to get a result i.e. it was initially necessary tocall ArraySize from the body
At each iteration, the loop's condition already contains a check of the i<ArraySize() or i<size
condition, i.e. at each iteration either a function or a variable is called.
Why should we put the object being tested into the body?
Logic itself prompts us to decide which one will be faster to handle. To a function or to a variable.
I don't care what the compiler calls it. I'm not relying on the compiler, I'm just using my common sense to figure out what's faster to handle from the reference point of view.
At each iteration, in the loop's condition, the condition i<ArraySize() or i<size
is checked anyway, which means that at each iteration either a function or a variable is accessed.
Why should we put the object being tested in the body?
Because we are the lucky ones who have this function and the function can be any other. And it is placed exactly in the body. I only duplicated it in an attempt to enhance its effect and address different arrays.
But it is wrong to add more complex tasks, the error of calculation of which may overshadow the effect under study. By the way it is also possible that the assembly is not constant in μl. i.e. when recompiling can get slightly different data (although this is not exact, but it's kind of used as protection against hacking) So everything can be tested on your code for you. See if the results change.
Mcl simply tries to substitute code as indicated in the video. Well it's a little bit different there. But in general terms.
And those instructions for functions that don't know what value they will get - that's how js and php and other similar languages work, even µl works this way but only in debug mode
At each iteration, in the loop's condition, the condition i<ArraySize() or i<size
is checked anyway, which means that at each iteration either a function or a variable is accessed.
Why should we put the object being tested into the body?
Logic itself prompts us to decide which one will be faster to handle. To a function or to a variable.
I don't care how the compiler binds it there. I don't rely on the compiler, I rely on common sense and figure out what is faster to handle from the reference point of view.
It doesn't always work.
Forum on trading, automated trading systems and trading strategy testing
Question for #define experts
Roman, 2020.11.02 19:44
Changed my post.
It is the other way round, i.e. ArraySize is faster now than cnt.
It was vice versa before. Maybe increment cnt-- affects, loop's body is different and probably something else must be invented for the load.