Errores, fallos, preguntas - página 2668

[fxsaber]

Sergey Dzyublik:

El problema es que si reservo la memoria y creo los elementos del array de uno en uno, tarda muchas veces más que si los creo todos a la vez.

No me di cuenta de esto en el código. Explica entonces, como sólo hay un si disparado, donde si el tamaño no ha cambiado, salir.

[Sergey Dzyublik]

fxsaber:

No me di cuenta de esto en el código. Explica entonces, como sólo hay un si disparado, donde si el tamaño no ha cambiado, salir.

Explicación del código anterior#2666

test1, crea todos los elementos de una sola vez en la primera llamada, las restantes llamadas de ArrayResize quedan "sin hacer nada".
El número total de llamadas ArrayResize == array_size:

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

test2, crea un elemento y reserva espacio para otro elemento array_size-1, el resto de llamadas a ArrayResize van a crear +1 elemento en el array desde la memoria previamente reservada.
El número total de llamadas a 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);
      }

* hubo un error en el código original (+- un elemento de diferencia). El código ha sido actualizado.
La pregunta sigue siendo: ¿por qué el algoritmo de test2 es 7 veces más lento que el de test1 para estructuras y 2 veces más lento para clases e int?

[Alain Verleyen]

Sergey Dzyublik :

Por mi parte, la comparación era lo que debía ser.
Sé cuántos elementos se pondrán en el array y, en lugar de crearlos todos a la vez, reservo memoria para los no creados.
El problema es que si reservo la memoria y creo los elementos del array uno a uno, tarda muchas veces más que si los creo todos a la vez.
Así que para las estructuras es 7 veces más lento.
Y es dos veces más lento para los tipos de datos class e int.

Esta es una diferencia muy grande, que creo que los desarrolladores pueden eliminar si lo desean.

OK en este caso, estoy de acuerdo en que sólo debe haber menores gastos generales.

Pero, en mi opinión, el problema es más bien la forma de comparar. El bucle de la prueba1 es probablemente optimizado y eliminado por el compilador, y tal vez incluso el siguiente:

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

Prueba el perfilador y sólo verás una pequeña diferencia.

[Alain Verleyen]

No hay optimización del compilador con el perfilador.

[fxsaber]

Sergey Dzyublik:

La pregunta sigue siendo: ¿por qué el test2 es más lento que el test1 para las estructuras por un factor de 7, y por un factor de 2 para las clases y los int?

Constructores por defecto.

[Sergey Dzyublik]

Alain Verleyen:

El bucle en test1 probablemente está optimizado y eliminado por el compilador

Si ejecuta el código#2666 anterior en modo Debug, verá resultados similares a los obtenidos anteriormente, ya que las ralentizaciones son causadas por el trabajo de la función ArrayResize y no por la optimización del código de usuario.
El modo de depuración se ejecuta sin ninguna optimización: se ejecuta lo que está escrito en el código y lo que se ejecuta es sólo nop-tipos para los puntos de interrupción de usuario se insertan entre las instrucciones.

[Aleksei Skrypnev]

No recibir SMS en el nuevo servicio confirmando la apertura de la cuenta demo por SMS. más detalles aquí.

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

[Alain Verleyen]

Sergey Dzyublik :

Si ejecuta el código anterior #2666 en modo Debug, verá resultados similares a los obtenidos anteriormente, ya que el retraso está en el trabajo de la función ArrayResize y no en la optimización del código de usuario.
El modo de depuración se ejecuta sin ninguna optimización: se ejecuta lo que está escrito en el código y lo que se ejecuta es sólo nop-tipos para los puntos de interrupción de usuario se insertan entre las instrucciones.

Como se muestra en el post #26674, no hay problemas con ArrayResize (), pero sólo con la prueba comparativa. A menos que me haya perdido algo.

[Sergey Dzyublik]

Alain Verleyen:
Como se muestra en el post #26674, no hay ningún problema con ArrayResize (), sino sólo con la prueba de comparación. A menos que me haya perdido algo.

El problema se detecta dentro de un proyecto real cuando se busca el cuello de botella para el algoritmo vector<T>::push_back.
El problema aparece como parte de la lenta ejecución de ArrayResize en presencia de memoria reservada tanto en compilaciones Release como Debug.

Usted afirma que todo está bien porque el perfilado no ha detectado nada.
A nadie le importan los resultados obtenidos.
Sin embargo, la ausencia de problemas aparentes durante la creación de perfiles no los anula en las compilaciones de lanzamiento y depuración, que son utilizadas por el 100% de los usuarios.

[Alain Verleyen]

Sergey Dzyublik :

El problema se detecta en un proyecto real mientras se busca el cuello de botella para el algoritmo vector<T>::push_back.
El problema aparece en la ejecución lenta de ArrayResize cuando hay memoria reservada tanto en las compilaciones Release como Debug.

Usted afirma que todo está bien porque el perfilado no ha detectado nada.
A nadie le importan los resultados obtenidos.
Sin embargo, la ausencia de problemas aparentes durante la creación de perfiles no los anula en las compilaciones de lanzamiento y depuración, que son utilizadas por el 100% de los usuarios.

Sólo puedo hablar del código de prueba que has proporcionado.

En cualquier caso, veamos qué tienen que decir los desarrolladores. Tal vez.