Is it possible to avoid many "ors" (||) in conditions causing the same action? - page 6

New comment
 
Meat:

borilunad, any function calls add unnecessary braking. Therefore, if maximum speed is required, you should get rid of all Request(), which performs one-syllable operations. The same applies to loops. Checking conditions in loop is always much slower than just a series of nested if()

So even mutually exclusive conditions are better with if(A || B || C || D) action;

But I can't avoid function calls, as I need to check a lot of data at that point, which is included in those conditions.

I'll continue my experiments, maybe I'll get something out of it. But there is no control over spread! :)

 
In general, the fastest option would be this:
bool result;
if (A) result=true;
else
if (B) result=true;
else
if (C) result=true;
else
if (D) result=true;
else result=false;

if (result) Action();

However,else result=false line should better be combined with the first one, it won't affect speed.In general, if A, B, C and D contain simple conditions (with minimum arithmetic, without calls of all math functions and other stuff), then you won't get much performance gain from such optimization (unless this construction runs tens of millions of times, of course). But code overloading can be significant.

I wrote about it in one of the threads that everything must be handled rationally. For some reason, it seems to me that your code is full of more important places optimization of which would really give a huge performance gain. You should start with the basic algorithm. Most newbies have a dumb check of all conditions concerning TS or open orders at every tick. But in most cases, it is enough to check only boundary conditions, for example when haul or low reaches a certain value, or when a new bar appears. Only after that you can perform further checks.

Well, besides with resource-intensive calculations you need to think about moving these calculations to a DLL. Otherwise, to sit and wait for 13 minutes in fucking MQL4 (while you can get the same result for 2-3 minutes) seems to be unfortunate :)

 
Meat:
In general, the fastest option would be this:

However,else result=false line should better be combined with the first one, it won't affect speed.In general, if A, B, C and D contain simple conditions (with minimum arithmetic, without calls of all math functions and other stuff), then you won't get much performance gain from such optimization (unless this construction runs tens of millions of times, of course). But code overloading can be significant.

I wrote about it in one of the threads that everything must be handled rationally. For some reason, it seems to me that your code is full of more important places optimization of which would really give a huge performance gain. You should start with the basic algorithm. Most newbies have a dumb check of all conditions concerning TS or open orders at every tick. But in most cases, it is enough to check only boundary conditions, for example when haul or low reaches a certain value, or when a new bar appears. Only after that you can perform further checks.

Well, besides with resource-intensive calculations you need to think about moving these calculations to a DLL. Otherwise, to sit and wait for 13 minutes in fucking MQL4 (while you can get the same result for 2-3 minutes) seems to be unfortunate :)

The fastest option was suggested by Paco
 
tara:
The fastest option was suggested by Paco

Do you really think it's faster to sum several values each time (i.e. to perform extra arithmetic operations)? In my variant the check is finished at the first match, while in the variant mentioned by you - only after summing up all values and then checking the sum.

Besides, that variant requires calculating ALL conditions in advance. So what kind of speed we're talking about here? It's the slowest option.

 
and switch - case is not a good idea?
 

If you want to speed up, you can try bitwise operations.

I.e. make all variables of int type (false=0). Then bitwise A|B|C...>0

 
Avals:

If you want to speed up, you can try bitwise operations.

I.e. make all variables of int type (false=0). Then bitwise A|B|C...>0

And what is the point of all this? Just like with summation, all the conditions must be precomputed. And why calculate them all, if only one of the conditions is enough.
 

And no one will check the suggested variants for speed of execution?

You can use the script from here

 
Meat:
In general, the fastest option would be this:

However,else result=false line should better be combined with the first one, it won't affect speed.In general, if A, B, C and D contain simple conditions (with minimum arithmetic, without calls of all math functions and other stuff), then you won't get much performance gain from such optimization (unless this construction runs tens of millions of times, of course). But code overloading can be significant.

I wrote about it in one of the threads that everything must be handled rationally. For some reason, it seems to me that your code is full of more important places optimization of which would really give a huge performance gain. You should start with the basic algorithm. Most newbies have a dumb check of all conditions concerning TS or open orders at every tick. But in most cases, it is enough to check only boundary conditions, for example when haul or low reaches a certain value, or when a new bar appears. Only after that you can perform further checks.

Well, besides with resource-intensive calculations you need to think about moving these calculations to a DLL. Otherwise it would be unfortunate to sit and wait for 13 minutes in fucking MQL4 (although we may get the same result in 2-3 minutes).

if (A) Action();
 else
  if (B) Action();
   else
    if (C) Action();
     else
      if (D) Action();

It's even faster that way.

I remember a story:

"At a company board meeting, there were two questions:

1. The decision to build a synchrophasotron.

2. The decision to build a bicycle car park for the employees.

On the first issue, the discussion lasted for 1 minute,

on the 2nd, the debate lasted more than 2 hours."

 
Whoever doesn't like "fucking MQL4" might as well go on a run, run. Because it is unclear what he is doing here. despite all the merits and antiquity of the account.
12345678910
New comment