Erros, bugs, perguntas - página 2668

[fxsaber]

Sergey Dzyublik:

O problema é que se eu reservar memória e criar elementos de matriz um de cada vez, leva muitas vezes mais tempo do que apenas criá-los todos de uma só vez.

Não reparei nisto no código. Explica então, como só há um se desencadeado, onde se o tamanho não tiver mudado, sair.

[Sergey Dzyublik]

fxsaber:

Não reparei nisto no código. Explica então, como só há um se desencadeado, onde se o tamanho não tiver mudado, sair.

Explicação do código acima#2666

test1, cria todos os elementos de uma só vez na primeira chamada, as restantes chamadas do ArrayResize vão "ociosas".
O número total de chamadas ArrayResize == tamanho_do_arquitecto:

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

test2, cria um elemento e reserva espaço para outro elemento array_size1, as restantes chamadas para o ArrayResize vão para criar +1 elemento no array a partir de memória previamente reservada.
O número total de chamadas para o ArrayResize == tamanho_do_arquitecto:

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

* houve um erro no código original (+- um elemento de diferença). O código foi actualizado.
A questão permanece: porque é que o algoritmo test2 é 7 vezes mais lento que o test1 para estruturas e 2 vezes mais lento para classes e int?

[Alain Verleyen]

Sergey Dzyublik :

Do meu lado, a comparação era o que deveria ser.
Sei quantos elementos serão colocados na matriz e, em vez de os criar todos de uma só vez, reservo a memória para os não criados.
O problema é que, se eu reservar memória e criar itens de matriz um por um, leva muitas vezes mais tempo do que apenas criá-los todos de uma só vez.
Assim, para estruturas, é 7 vezes mais lento.
E é duas vezes mais lento para os tipos de dados de classe e int.

Esta é uma diferença muito grande, que penso que os criadores podem eliminar se assim o desejarem.

OK, neste caso, concordo que só deve haver despesas gerais mais baixas.

Mas, na minha opinião, o problema é mais a forma como se compara. O laço no teste1 é provavelmente optimizado e removido pelo compilador, e talvez mesmo a seguir:

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

Experimente o perfilador e verá apenas uma pequena diferença.

[Alain Verleyen]

Sem optimização do compilador com o perfilador.

[fxsaber]

Sergey Dzyublik:

A questão permanece: porque é que o teste2 é mais lento que o teste1 para estruturas por um factor 7, e por um factor 2 para classes e int?

Construtores por defeito.

[Sergey Dzyublik]

Alain Verleyen:

O laço no teste1 é provavelmente optimizado e removido pelo compilador

Se executar o código acima#2666 no modo Debug, verá resultados semelhantes aos obtidos anteriormente, uma vez que os abrandamentos são causados pelo trabalho da função ArrayResize e não pela optimização do código do utilizador.
O modo de depuração é executado sem qualquer optimização: o que está escrito no código é executado e o que é executado é apenas nop-types para pontos de interrupção do utilizador são inseridos entre as instruções.

[Aleksei Skrypnev]

Não receber SMS em novo serviço confirmando a abertura de conta de demonstração por SMS. mais detalhes aqui.

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

[Alain Verleyen]

Sergey Dzyublik :

Se executar o código acima #2666 em modo Debug, verá resultados semelhantes aos obtidos anteriormente, pois o atraso está no trabalho da função ArrayResize e não na optimização do código do utilizador.
O modo de depuração é executado sem qualquer optimização: o que está escrito no código é executado, os nops são simplesmente inseridos entre as instruções para os pontos de interrupção do utilizador.

Como mostrado no post #26674, sem problemas com o ArrayResize (), mas apenas com teste comparativo. A menos que me tenha escapado alguma coisa.

[Sergey Dzyublik]

Alain Verleyen:
Como mostrado no post #26674, não há problema com o ArrayResize (), mas apenas com o teste de comparação. A menos que me tenha escapado alguma coisa.

O problema é detectado dentro de um projecto real quando se procura um estrangulamento para o vector<T>::push_back algoritmo.
O problema aparece como parte da lenta execução do ArrayResize na presença de memória reservada em ambas as compilações Release e Debug.

Afirma que está tudo bem porque a caracterização não detectou nada.
Ninguém se preocupa com os resultados obtidos.
No entanto, a ausência de problemas aparentes durante a criação de perfis não os cancela nas compilações Release e Debug que são utilizadas por 100% dos utilizadores.

[Alain Verleyen]

Sergey Dzyublik :

O problema é detectado dentro de um projecto real enquanto se procura um estrangulamento para o vector<T>::push_back algoritmo.
O problema aparece dentro da execução lenta do ArrayResize quando há memória reservada tanto em compilações Release como Debug.

Afirma que está tudo bem porque a caracterização não detectou nada.
Ninguém se preocupa com os resultados obtidos.
No entanto, a ausência de problemas aparentes durante a criação de perfis não os cancela nas compilações Release e Debug que são utilizadas por 100% dos utilizadores.

Só posso falar sobre o código de teste que forneceu.

Em qualquer caso, vamos ver o que os criadores têm a dizer. Talvez.