In which way program performance is best? - page 2

New comment
 
amrali #:
I would better make sure the program runs as intended first before any optimizations (the testing stage). After that I can use the profiler to check bottlenecks in the code (the macro-optimization stage). 

If you find this piece of code you posted is slow in profiler, then you can micro-optimize its execution time (via GetTickCount or GetMicrosecondsCount). This is the micro-optimization stage.

But, frankly I do not see any difference between these 2 code snippets. 

Choosing one of them, is a matter of your coding style. Personally, I prefer clear code, not giving any consideration for how many  lines it takes. 

Completely agree, without having the code in front and without knowing the intentions, it's absurd to determine which of the two formulas is better. The best advice is to use a profiler and conduct tests. However, I insist, in this specific case (without complex calculations), it's like debating; What is heavier? 1 kilogram or 1 liter.

 
Dominik Egert #:
What??

No. - Calling a function (in this case two functions, iClose and iOpen) multiple times is slower than calling a function once and storing the result.

How do you come up with such an idea?

But the iX functions fetch stuff from memory too right ? Its not a calculation

 
Lorentzos Roussos #: But the iX functions fetch stuff from memory too right ? Its not a calculation

Both. It's a calculation that is also being stored to be called later, so efficiency (unless there is an intention to use it later) is null.

 
Miguel Angel Vico Alba #:

Both. It's a calculation that is also being stored to be called later, so efficiency (unless there is an intention to use it later) is null.

So its doing the same thing as storing it in a variable

 
Lorentzos Roussos #: So its doing the same thing as storing it in a variable

Forum on trading, automated trading systems and testing trading strategies

In which way program performance is best?

Miguel Angel Vico Alba, 2024.01.07 11:29

Both. It's a calculation that is also being stored to be called later, so efficiency (unless there is an intention to use it later) is null.

I was referring to the first example. This:

int bar = 10;
double open   = iOpen(_Symbol, PERIOD_M1, bar);
double close  = iClose(_Symbol, PERIOD_M1, bar);

if(open>close)

Logically, the second example is the most efficient in simple terms without taking into account the rest of the code or what it is intended to do in general terms with it.

if (iOpen(_Symbol, PERIOD_M1, 10)>iClose(_Symbol, PERIOD_M1, 10))

Edit:

I said "both" based on your comment that if the iX functions also reclaim memory and don't calculate. My response is that example 1 does both things (they are calculated and stored).

Also, you perfectly know what the topic is about... don't troll me! 😅🤣

 
Lorentzos Roussos #:

But the iX functions fetch stuff from memory too right ? Its not a calculation

It doesnt matter. - Here is why:

iOpen and iClose are precompiled binary functions, provided by the terminal. - Your code has to do a jmp operation to call the functions. This includes a stack push, function stack initialization and, after the function (iClose) has done what it needs to do, a result push to the calling function, ending with a jmp back to the caller, in this case your function.

Now since the result needs to be stored on the stack of (your function) the caller, a memory area needs to be assigned anyways, let it be a dedicated variable, you define, or let it be an implicit declaration by the compiler. - No difference.

There is however a difference in calling an API function once or multiple times, the compiler is unable to optimize your callings, since the result of that calling is unknown at that point, also cacheing cannot be applied, as the code of the API function is precompiled, its inner workings re unknown to your code.

So no matter how or what you do, calling a (precompiled) function will under all circumstances result in a stack push jump and return. . Hence slower than calling the function once and storing the result in an explicit declared variable.

And it is completley irrelevant what the function you are calling actually does, accessing memory (pointer-arithmetic) or calculations on its input parameters, the penalty is always the same.


(End of story and discussion.... - Haha)

 
Dominik Egert #:

It doesnt matter. - Here is why:

iOpen and iClose are precompiled binary functions, provided by the terminal. - Your code has to do a jmp operation to call the functions. This includes a stack push, function stack initialization and, after the function (iClose) has done what it needs to do, a result push to the calling function, ending with a jmp back to the caller, in this case your function.

Now since the result needs to be stored on the stack of (your function) the caller, a memory area needs to be assigned anyways, let it be a dedicated variable, you define, or let it be an implicit declaration by the compiler. - No difference.

There is however a difference in calling an API function once or multiple times, the compiler is unable to optimize your callings, since the result of that calling is unknown at that point, also cacheing cannot be applied, as the code of the API function is precompiled, its inner workings re unknown to your code.

So no matter how or what you do, calling a (precompiled) function will under all circumstances result in a stack push jump and return. . Hence slower than calling the function once and storing the result in an explicit declared variable.

And it is completley irrelevant what the function you are calling actually does, accessing memory (pointer-arithmetic) or calculations on its input parameters, the penalty is always the same.


(End of story and discussion.... - Haha)

Serious existential doubt.

Could that not have been your first answer or did you need 4 hours to read? I am surprised how in your first intervention you had doubts and now hours later you make an illustration ChatGPT style settling cathedra.

No offence, it's just a doubt. As you can understand, it is all very strange.

 
Miguel Angel Vico Alba #:

Serious existential doubt.

Could that not have been your first answer or did you need 4 hours to read? I am surprised how in your first intervention you had doubts and now hours later you make an illustration ChatGPT style settling cathedra.

No offence, it's just a doubt. As you can understand, it is all very strange.

I understand.

In my first reply, I answered exactly what was asked. Listing 1 == Listing 2.

The problem is, and that's why I kept back with detailed explanation, there is no way to proof it is factual that way, since we cannot dissolve mql5 to assembly.

So the answer was taken from general knowledge, and my detailed explanation is factual from c/c++ where I can proof it.

But assuming common sense by the mql5 compiler devs, I gave this as a hard explanation.

And, No, not GPT. I never tried GPT, I was gifted with a brain, don't need external replacement... ;-)

 
Dominik Egert #:
I understand.

In my first reply, I answered exactly what was asked. Listing 1 == Listing 2.

The problem is, and that's why I kept back with detailed explanation, there is no way to proof it is factual that way, since we cannot dissolve mql5 to assembly.

So the answer was taken from general knowledge, and my detailed explanation is factual from c/c++ where I can proof it.

But assuming common sense by the mql5 compiler devs, I gave this as a hard explanation.

And, No, not GPT. I never tried GPT, I was gifted with a brain, don't need external replacement... ;-)

Thank you. I sincerely appreciate that you didn't take it as an offence.

Glad to know that at least someone on the forum has a brain! 😅🤣

 

If you want performance, do not use iOpen, iClose or other iXXX functions. Use CopyXXX functions.

If you want performance, you need to use more memory. In general, memory usage and performance are correlated.

123
New comment
Reason: