Errors, bugs, questions - page 2668

[fxsaber]

Sergey Dzyublik:

The problem is that if I reserve memory and create array elements one at a time, it takes many times longer than just creating them all at once.

Didn't notice this in the code. Explains then, as there's only one if triggered, where if the size hasn't changed, exit.

[Sergey Dzyublik]

fxsaber:

Didn't notice this in the code. Explains then, as there's only one if triggered, where if the size hasn't changed, exit.

Explanation of the above code#2666

test1, creates all elements at once at the first call, the remaining calls of ArrayResize go "idle".
The total number of ArrayResize calls == array_size:

      T class_array[];
      for(int i = 1; i <= array_size; i++){
         ArrayResize(class_array, array_size);
      }

test2, creates one element and reserves space for another array_size-1 element, the remaining calls to ArrayResize go to create +1 element in the array from previously reserved memory.
The total number of calls to ArrayResize == array_size:

      T class_array[];
      ArrayResize(class_array, 1, array_size - 1);
      for(int i = 2; i <= array_size; i++){
         ArrayResize(class_array, i);
      }

* there was an error in the original code (+- one element difference). The code has been updated.
The question remains: why is test2 algorithm 7 times slower than test1 for structures and 2 times slower for classes and int?

[Alain Verleyen]

Sergey Dzyublik :

On my side the comparison was what it was supposed to be.
I know how many elements will be put into the array and, instead of creating them all at once, I reserve memory for uncreated ones.
The problem is, if I reserve memory and create array items one by one, it takes many times longer than just creating them all at once.
So for structures it is 7 times slower.
And it is twice slower for the class and int data types.

This is a very big difference, which I think developers can eliminate if they wish.

OK in this case, I agree that there should only be lower overheads.

But I think the problem is more the way you compare. The loop in test1 is probably optimised and removed by the compiler, and maybe even next:

 for ( ulong ii= 0 ;ii<count&&! _StopFlag ;ii++)

Try the profiler and you will only see a small difference.

[Alain Verleyen]

No compiler optimisation with the profiler.

[fxsaber]

Sergey Dzyublik:

The question remains: why is test2 slower than test1 for structures by a factor of 7, and by a factor of 2 for classes and int?

Default constructors.

[Sergey Dzyublik]

Alain Verleyen:

The loop in test1 is probably optimised and removed by the compiler

If you run the above code#2666 in Debug mode, you will see results similar to those obtained earlier, as the slowdowns are caused by the ArrayResize function's work and not by optimization of user code.
Debug mode is executed without any optimizations: what is written in the code is executed and what is executed is just nop-types for user breakpoints are inserted between instructions.

[Aleksei Skrypnev]

Not getting SMS on new service confirming opening of demo account by SMS. more details here.

https://www.mql5.com/ru/forum/334179#comment_1529250

[Alain Verleyen]

Sergey Dzyublik :

If you run the above code #2666 in Debug mode, you will see results similar to those obtained earlier, as the lag is in the ArrayResize function's work and not in the optimization of the user code.
Debug mode is executed without any optimizations: what is written in the code is executed and what is executed is just nop-types for user breakpoints are inserted between instructions.

As shown in post #26674, no problems with ArrayResize (), but only with comparative test. Unless I missed something.

[Sergey Dzyublik]

Alain Verleyen:
As shown in post #26674, there is no problem with ArrayResize (), but only with the comparison test. Unless I missed something.

The problem is detected within a real project when looking for bottleneck for vector<T>::push_back algorithm.
The problem appears as part of the slow execution of ArrayResize in the presence of reserved memory in both Release and Debug compilations.

You claim everything is ok because the profiling has not detected anything.
No one minds the results obtained.
However, absence of apparent issues during profiling doesn't cancel cancel them out in Release and Debug compilations which are used by 100% of users.

[Alain Verleyen]

Sergey Dzyublik :

The problem is detected within real project while searching for bottleneck for vector<T>::push_back algorithm.
The problem appears within slow execution of ArrayResize when there is reserved memory both in Release and Debug compilations.

You claim everything is ok because the profiling has not detected anything.
No one minds the results obtained.
However, absence of apparent issues during profiling doesn't cancel cancel them out in Release and Debug compilations which are used by 100% of users.

I can only talk about the test code you provided.

In any case, let's see what the developers have to say. Maybe.