Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Aun así, el código superior a veces gana, pero muy raramente, es decir, el enlace es libre
) bueno, no es así como funciona)
Así es como funciona en C++
En mql creo que es lo mismo pero con wrappers adicionales de MQ
Foro sobre trading, sistemas de trading automatizados y comprobación de estrategias
FAQ de principiantes MQL5 MT5 MetaTrader 5
Roman, 2019.12.11 14:02
No tienes que pensarlo bien, por qué debería... El compilador lo hará todo por sí mismo. ))
C# no es C
Echa un vistazo al vídeo sobre __inline.
Allí se explica cómo funcionan las funciones en la memoria para los que no hacen ninguna diferencia.
Así es como funciona en C++
En mql creo que es lo mismo, pero con wrappers adicionales de MQ
Bueno, ahora releer este hilo y un montón de declaraciones y ejemplos de prueba - que hay alguna diferencia. Y lo encontramos)))
Pues ahora relee este hilo y un montón de declaraciones y ejemplos de pruebas - que hay una diferencia. Y lo hicieron))))
No )) No tengo ningún deseo de releerlo.
Para mí es obvio que hay una diferencia.
No )) No tengo ningún deseo de releerlo.
Para mí es obvio que hay una diferencia.
)))) otro IMHO.
La vía superior es más rápida en casi un 15% esto es muy significativo, bueno si todo es tan obvio explíquenmelo)
)))) otro IMHO
La vía superior es más rápida en casi un 20%, bueno ya que todo es tan obvio explícamelo)
Los bucles que se comparan no son iguales en cuanto a código en el cuerpo.
El primer bucle tiene un código en el cuerpo, el cuerpo del segundo bucle tiene otro código.
Naturalmente, instrucciones de código diferentes, naturalmente, tiempo de ejecución diferente.
Haz el mismo código en el cuerpo del bucle y cambia sólo la condición del bucle ArraySize y la variable size.
Estamos probando esta parte, no el cuerpo.
Los bucles que se comparan no son el mismo código en el cuerpo.
El primer bucle tiene un código en su cuerpo y el cuerpo del segundo bucle tiene otro código.
Naturalmente, las instrucciones del código y el tiempo de ejecución son diferentes.
Haz el mismo código en el cuerpo del bucle y cambia sólo la condición del bucle ArraySize y la variable size.
Estamos probando esta parte, no el cuerpo.
Tu prueba es más incorrecta porque depende del caso de lanzamiento, ejecútala de nuevo. En ambos casos hay un incremento y una división. Bueno, además hay un par de decenas~ miles de millones adicionales de llamadas a ArraySize en la parte superior.
Por cierto, es en el cuerpo donde debemos escribir lo que estamos probando. Porque es el cuerpo el que se repite. Estamos tratando de envolverlo en loop.... para obtener un resultado es decir, originalmente era necesariollamar a ArraySize desde el cuerpo
Tu prueba es más incorrecta ya que depende del caso de lanzamiento, ejecútala de nuevo. Aquí ambos casos tienen un incremento y una división. Bueno, además hay un par de decenas~ miles de millones de llamadas ArraySize en la parte superior.
Por cierto, es en el cuerpo donde debemos escribir lo que estamos probando. Porque es el cuerpo el que se repite. Estamos tratando de envolverlo en loop.... para obtener un resultado es decir, inicialmente era necesariollamar a ArraySize desde el cuerpo
En cada iteración, la condición del bucle ya contiene una comprobación de la condición i<ArraySize() o i<size
, es decir, en cada iteración se llama a una función o a una variable.
¿Por qué debemos introducir el objeto que se está probando en el cuerpo?
La propia lógica nos lleva a decidir cuál será más rápido de manejar. A una función o a una variable.
No me importa cómo lo llame el compilador. No confío en el compilador, sólo utilizo mi sentido común para averiguar qué es más rápido de manejar desde el punto de vista de la referencia.
En cada iteración, en la condición del bucle, se comprueba de todas formas la condición i<ArraySize() o i<size
, lo que significa que en cada iteración se accede a una función o a una variable.
¿Por qué hay que poner el objeto que se examina en el cuerpo?
Porque somos los afortunados que tenemos esta función y la función puede ser cualquier otra. Y se coloca exactamente en el cuerpo. Sólo lo he duplicado para intentar potenciar su efecto y abordar diferentes matrices.
Pero es un error añadir tareas más complejas, cuyo error de cálculo puede eclipsar el efecto estudiado. Por cierto también es posible que el montaje no es constante en μl. es decir, cuando la recompilación puede obtener datos ligeramente diferentes (aunque esto no es exacto, pero es una especie de protección contra la piratería) Así que todo puede ser probado en su código para usted. Vea si los resultados cambian.
Mcl simplemente intenta sustituir el código como se indica en el vídeo. Bueno, es un poco diferente allí. Pero en términos generales.
Y esas instrucciones para las funciones que no saben qué valor van a obtener - así es como funcionan js y php y otros lenguajes similares, incluso µl funciona así pero sólo en modo debug
En cada iteración, en la condición del bucle, se comprueba de todas formas la condición i<ArraySize() o i<size
, lo que significa que en cada iteración se accede a una función o a una variable.
¿Por qué debemos introducir el objeto que se está probando en el cuerpo?
La propia lógica nos lleva a decidir cuál será más rápido de manejar. A una función o a una variable.
No me importa cómo lo llame el compilador. No confío en el compilador, sino en el sentido común y en averiguar qué es más rápido de manejar desde el punto de vista de la referencia.
No siempre funciona.
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Pregunta para los expertos en #define
Roman, 2020.11.02 19:44
Cambié mi puesto.
Es al revés, es decir, ArraySize es más rápido ahora que cnt.
Antes era al revés. Tal vez el incremento de cnt-- afecta, el cuerpo del bucle es diferente y probablemente algo más debe ser inventado para la carga.