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
Estimados desarrolladores, ¿podrían informarme de cómo se calcula MQL_MEMORY_USED?
He hecho un cálculo de la memoria que ocupan todas las variables de EA.
Es menos del 10%. Si he entendido bien, MQL_MEMORY_USED incluye la caché del historial y la caché de CopyTicks. Pero sigue siendo mucho menos.
Al mismo tiempo, el Asesor Experto paralelo consume varias veces menos. Pero el principio es el mismo.
En general, ¿qué se incluye a este valor?
He guardado una plantilla con Expert Advisor y la he aplicado al mismo gráfico provocando la recarga. Lo he visto así.
El uso de la memoria ha cambiado en casi un orden de magnitud. Hasta ahora, es difícil explicar lo que significa.
Muchos programas tienen un efecto acumulativo de uso de memoria. Esto es un pecado de los navegadores y a veces incluso de Word. La Terminal también puede ser culpable de ello. Además, todos los registros se escriben por defecto y es fácil pasar una semana si tienes demasiadas acciones en un giga. Es un mal que hay que gestionar. Pero no está claro cómo.
¿Tal vez sepa cómo seleccionar mediante programación un instrumento financiero y no quedarse colgado durante mucho tiempo?
A través de un indicador
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
MT5 y Speed en acción
Renat Fatkhullin, 2020.10.14 04:15
Para el ticking masivo pon más memoria.
4gb (precio de 20 euros) no es bueno en 2020 cuando se trata de análisis e investigación.
Para los productos de mercado, este enfoque no es bueno en ninguna parte. Tenemos que evitar la retención de 10 segundos de datos innecesarios a través de dicha muleta.
Hacer un producto de mercado trivial en forma de un Market Screener no es realmente una tarea alcanzable para MT5 debido al excesivo consumo de memoria.
Hacer un producto de mercado trivial en forma de Market Screener no es realmente una tarea alcanzable para la MT5 debido al excesivo consumo de memoria.
El terminal come mucha memoria después del lanzamiento.
Después de la ejecución del screener empezó a comer 2 gigas (TERMINAL_MEMORY_USED y no disminuyó con el tiempo). Esto es con un solo gráfico abierto para 5000 barras M1.
No se ha guardado una captura de pantalla. Pero decidió lanzar un ejemplo, que muestra la memoria comer Terminal no en sí mismo, donde es simplemente estúpido.
El script sólo hace copias de los símbolos originales del Market Watch. Se supone que debo añadir todos los símbolos en MQ-Demo y ejecutar este script primero en frío y luego en caliente.
Y después de la ejecución en caliente (cuando los ticks ya están en SSD en forma de archivos tkc) observaré un enorme agotamiento de la memoria donde no es necesario en una implementación adecuada.
Sin embargo, al ejecutar el script, me he encontrado con que se cuelga en MQ-Demo. Sólo puede descargarse a través de la terminación anormal, tras la cual el Terminal no libera más de 1 GB de memoria.
Es fácil comparar esta captura de pantalla con la del principio.
Lo siento, no estoy seguro de si esto es un error o una característica. No he encontrado una respuesta por mi cuenta. Pero la pregunta está relacionada con el rendimiento y supongo que es mejor hacerla aquí.
Si añadimos, por ejemplo, 22 búferes de tipo DRAW_SECTION a un indicador vacío, entonces al inicio de dicho indicador para un gráfico que contenga 1000000 barras o más, el terminal se retrasa significativamente (provoca una carga importante de la CPU) y consume cantidades significativas de memoria, incluso si el indicador no calcula nada.
Mi interés se ha despertado por el hecho de que si se utilizan buffers con otros tipos, todo funciona sin problemas y no se observa esa ralentización.
Por ejemplo, he ejecutado el siguiente código en un solo gráfico con 1000000 barras y ha consumido unos 500 MBytes y se retrasa, sobre todo el propio gráfico.
Pero si cambio el tipo de búfer a, por ejemplo, DRAW_LINE, la carga del procesador se reduce drásticamente, no se observan retrasos y la memoria consume 5 veces menos (unos 100 MBytes consumidos).
Se hicieron pruebas similares en diferentes builds, hasta la de 2019 y la situación es la misma.
Un ciudadano particular sacó de sus amplios pantalonesun duplicado de una carga inestimable de código MQL, que demostró que en las mismas condiciones la muleta funcionaba más rápido que la función normal.
Una prueba muy sencilla:
20 Asesores Expertos en EURUSD, es decir, todos los procesos OnTick simultáneamente. La construcción de la terminal es 2664. La prueba se ejecuta sin optimización, compilación y otra carga adicional al 100% de la CPU - no vas a ejecutar un comercio real "hft" en este fondo, ¿verdad?
Típico registro de pruebas:
Una prueba muy sencilla:
20 EAs en EURUSD, es decir, todos los procesos OnTick al mismo tiempo. Terminal build 2664. La prueba se ejecuta sin optimización, compilación y otra carga de trabajo adicional en el 100% de la CPU - no vas a ejecutar un comercio real "hft" en este fondo, ¿verdad?
Típico registro de pruebas:
Se crean condiciones de invernadero haciendo 100K iteraciones durante 1,5 segundos en el mismo tick. Yo, en cambio, esperé a propósito los ticks que no generaron un OnTick.
Mirando mis registros de operaciones, me doy cuenta de la ejecución de SymbolInfoTick en unos pocos milisegundos. Y sé al 100% que la CPU estaba a pleno rendimiento en ese momento.
Es muy sencillo. Hay condicionalmente 1 millón de garrapatas al día. Incluso un 0,01% de ralentización de los ticks son 100 ticks al día con retrasos. Dirás que eso es una tontería. Diré que es malo. Si me encuentro con un retraso cuando tengo que hacer un pedido, es una pérdida monetaria potencial.
Se agradece mucho que esta rama no pase desapercibida, y en esta característica en particular, se ha trabajado mucho para agilizar las cosas. Sin embargo, me sorprendió un poco que la horrible muleta pudiera superar a la función normal en ciertas situaciones. Y tal vez si se ordenara y eliminara ese desfase, 100 desfases potenciales al día se convertirían en 10.
Yo digo que está mucho mejor que al principio del hilo. Pero el hecho es que hay veces que no es bueno. Y veo que no quieres investigarlo. Respeto su elección.
Arriba se citó la opción de la instantánea para obtener los precios actuales. Me convendría completamente si no cogiera lapsos de milisegundos en la máquina Idle-CPU.
También me preocupa no sólo la velocidad de SymbolInfoTick, sino también la relevancia de los precios que devuelve. Veo que no se plantea esta cuestión. Al parecer, decidiste mirarlo más tarde.
Se crean condiciones de invernadero haciendo 100K iteraciones en 1,5 segundos en el mismo tick. Yo, en cambio, esperé específicamente a los ticks que no generaban OnTick.
Al revisar mis registros de operaciones, observo que SymbolInfoTick se ejecuta durante unos pocos milisegundos. Sé al 100% que la CPU estaba en reposo en ese momento.Es muy sencillo. En un día hay condicionalmente 1 millón de garrapatas. Incluso un desfase del 0,01% son 100 ticks al día con desfases. Dirás que eso es una tontería. Diré que es malo. Si me encuentro con un retraso cuando tengo que hacer un pedido, es una pérdida monetaria potencial.
Se agradece mucho que esta rama no pase desapercibida, y en esta característica en particular, se ha trabajado mucho para agilizar las cosas. Sin embargo, me sorprendió un poco que la horrible muleta pudiera superar a la función normal en ciertas situaciones. Y tal vez si se ordenara y eliminara ese desfase, 100 desfases potenciales al día se convertirían en 10.
Yo digo que está mucho mejor que al principio del hilo. Pero el hecho es que hay veces que no es bueno. Y veo que no quieres investigarlo. Respeto su elección.
Arriba se citó la opción de la instantánea para obtener los precios actuales. Me convendría completamente si no cogiera lapsos de milisegundos en la máquina Idle-CPU.
También me preocupa no sólo la velocidad de SymbolInfoTick, sino también la relevancia de los precios que devuelve. Veo que no se plantea esta cuestión. Al parecer, decidiste mirarlo más tarde.
Estas no son condiciones cálidas en absoluto. Un bucle para 100000 peticiones de precio sin Sleep() y similares y en 20 hilos simultáneamente es una prueba de estrés evidente. Nada de eso debería estar siquiera cerca en condiciones reales.
Si crees que no hay más ticks en 1,5 segundos - vale, haz 10 millones de consultas, no cambiará nada, tu "muleta" funciona peor:Esta su afirmación es 100% falsa:
Al igual que esta declaración anterior suya:
El acceso a los precios a través de SymbolInfoTick es ahora muy rápido y está completamente desacoplado del procesamiento del flujo de ticks. Se trabaja con un caché de precios ya hecho, que se actualiza muy poco y rápidamente.
Todas las "ralentizaciones del 0,01% de la tasa de tick" sólo aparecen en condiciones de prueba de estrés, y eso es un gran resultado. En condiciones normales, se garantiza que el acceso sea muy rápido.
Si admite que "se ha trabajado mucho para agilizar" SymbolInfoTick, entonces debería creerme que la "muleta" de obtener los precios mediante PositionSelectByTicket no puede ser una solución mejor.
Por una simple razón - la implementación de PositionSelectByTicket es completamente idéntica a la implementación original "lenta" de SymbolInfoTick.
Como escribí anteriormente, esta implementación no es lenta en el sentido literal de la palabra, pero bajo una fuerte carga de la CPU, tiene una mayor probabilidad de que se produzcan valores atípicos en tiempo de ejecución (lo que es claramente visible en mi última prueba).
Los tiempos aquí dependen en gran medida del programador de tareas del sistema que se ejecuta bajo carga, es decir, puede haber diferencias de un sistema operativo a otro e incluso de una versión a otra.
Y cuanto más pesada sea la carga, más se probará el rendimiento del programador de tareas, no del terminal.
Este es el final del tema del rendimiento de SymbolInfoTick.
Si sus expertos crean una carga al nivel de las pruebas de estrés sintéticas, entonces hay una solución: "el hierro debe coincidir con las tareas".
Tengo una pregunta sobre la relevancia de los ticks dados por SymbolInfoTick.
Situación:
1. Hacemos TimeCurretn(); obtenemos la hora 18:00:00
2. Hacer SymbolInfoTick en un símbolo no etiquetado. Obtenemos una marca con la hora 17:58:00.
3. Dormir(1)
4. Añade un SymbolInfoTick para el símbolo no izquierdo. Obtenemos una marca con la hora 17:59:00.
Es decir, en el cuarto elemento tenemos un nuevo tick, que es un minuto diferente al de TimeCurretn().
¿Ves algún problema en esta situación?
¿Cómo llegar a esta situación con menos frecuencia?
Tengo una pregunta sobre la relevancia de los ticks dados por SymbolInfoTick.
Situación:
1. Hacemos TimeCurretn(); obtenemos la hora 18:00:00
2. Hacer SymbolInfoTick en un símbolo no etiquetado. Obtenemos una marca con la hora 17:58:00.
3. Dormir(1)
4. Añade un SymbolInfoTick para el símbolo no izquierdo. Obtenemos una marca con la hora 17:59:00.
Es decir, en el cuarto elemento tenemos un nuevo tick, que es un minuto diferente al de TimeCurretn().
¿Ves algún problema en esta situación?
¿Cómo llegar a esta situación con menos frecuencia?
SymbolInfoTick envía los datos recibidos del servidor del corredor. Lo que el servidor envió es lo que se obtiene.
Si tiene alguna duda sobre el flujo de ticks que emite su corredor, debe ponerse en contacto con él.