Ошибки, баги, вопросы - страница 2668

[fxsaber]

Sergey Dzyublik:

Проблема в том, что если резервирую память, а создаю элементы массива по одному, то это требует в разы больше времени, чем просто создать все сразу.

Не заметил этого в коде. Тогда объяснимо, т.к. там только один if срабатывает, где если размер не поменялся, выходим.

[Sergey Dzyublik]

fxsaber:

Не заметил этого в коде. Тогда объяснимо, т.к. там только один if срабатывает, где если размер не поменялся, выходим.

Пояснение относительно приведенного выше кода #26666

test1, создает все элементы стразу при первом вызове, остальные вызовы ArrayResize идут в "холостую".
Общее количество вызовов ArrayResize == array_size:

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

test2, создает один элемент и резервирует место еще для array_size-1 элемент, остальные вызовы ArrayResize идут для создании +1 элемента в массиве из ранее зарезервированной памяти.
Общее количество вызовов 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);
      }

* в изначальном коде была ошибка (разница +- один элемент). Код обновлен.
Вопрос остается открытым: почему алгоритм test2 медленнее test1 для структур в 7 раз, а для классов и int - в 2 раза?

[Alain Verleyen]

Sergey Dzyublik :

С моей стороны сравнивалось то, что должно было быть.
Мне известно сколько элементов будет помещено в массив и вместо того, что бы создавать их все сразу - резервирую память под несозданные.
Проблема в том, что если резервирую память, а создаю элементы массива по одному, то это требует в разы больше времени, чем просто создать все сразу.
Так для стуктур - это в 7 раз медленнее.
А для типов данных класс и int - в два раза медленнее.

Это очень большая разница, которую, как мне кажется, при желании разработчики могут устранить.

Хорошо в этом случае, я согласен, что должны быть только меньшие накладные расходы.

Но, на мой взгляд, проблема скорее в том, как вы сравниваете. Цикл в test1, скорее всего, оптимизирован и удален компилятором, и, возможно, даже следующим:

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

Попробуйте профилировщик, и вы увидите только небольшую разницу.

[Alain Verleyen]

Нет оптимизации компилятора с помощью профилировщика.

[fxsaber]

Sergey Dzyublik:

Вопрос остается открытым: почему алгоритм test2 медленнее test1 для структур в 7 раз, а для классов и int - в 2 раза?

Конструкторы по-умолчанию.

[Sergey Dzyublik]

Alain Verleyen:

Цикл в test1, скорее всего, оптимизирован и удален компилятором

Если приведенный код #26666 запустить в Debug режиме, то можно увидеть результаты, аналогичные полученным ранее данным, так как тормоза в работе функции ArrayResize, а не в оптимизации пользовательского кода.
Debug режиме выполняется без каких-либо оптимизаций - что написано в коде то и исполняется, просто между инструкциями вставляются  nop-ы  для пользовательских breakpoints.

[Aleksei Skrypnev]

Не доходят смс по новому сервису подтверждалка открытия демо счета по смс. подробнее тут.

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

[Alain Verleyen]

Sergey Dzyublik :

Если приведенный код  #26666  запустить в Debug режиме, то можно увидеть результаты, аналогичные полученным ранее данным, так как тормоза в работе функции ArrayResize, а не в оптимизации пользовательского кода.
Debug режиме выполняется без каких-либо оптимизаций - что написано в коде то и исполняется, просто между инструкциями вставляются  nop-ы  для пользовательских breakpoints.

Как показано в посте № 26674 , с ArrayResize () проблем нет, но только с сравнительным тестом. Если только я не пропустил что-то.

[Sergey Dzyublik]

Alain Verleyen:
Как показано в посте № 26674 , с ArrayResize () проблем нет, но только с сравнительным тестом. Если только я не пропустил что-то.

Проблема обнаружена в рамках реального проекта при поиске bottleneck для алгоритма vector<T>::push_back.
Проблема проявляется в рамках медленного выполнения ArrayResize при наличии reserved памяти как в Release так и Debug компиляциях.

Вы же утверждаете что все ок, так как профайлинг ни чего не обнаружил.
Ни кто не против полученных результатов.
Однако, отсутствие видимости проблем во время профилирования не отменяет их наличие в Release и Debug компиляциях, которыми и пользуются 100% пользователей.

[Alain Verleyen]

Sergey Dzyublik :

Проблема обнаружена в рамках реального проекта при поиске bottleneck для алгоритма vector<T>::push_back.
Проблема проявляется в рамках медленного выполнения ArrayResize при наличии reserved памяти как в Release так и Debug компиляциях.

Вы же утверждаете что все ок, так как профайлинг ни чего не обнаружил.
Ни кто не против полученных результатов.
Однако, отсутствие видимости проблем во время профилирования не отменяет их наличие в Release и Debug компиляциях, которыми и пользуются 100% пользователей.

Я могу говорить только о тестовом коде, который вы предоставили.

В любом случае, посмотрим, что скажут разработчики. Может быть.