MT5 y la velocidad en acción - página 23
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
Por si alguien no lo pilla, es la librería fxsaber que aplicada en código ajeno da frenos.
En lugar de señalarlo explícitamente, se puso a jugar a frenar la plataforma y a deslizar ejemplos suicidas. Y cuando hubo una oportunidad de llegar a la verdadera causa y limar asperezas, no la aprovechó.
En aras de la optimización local, estaba envenenando la caché del historial de la aplicación principal.Foro sobre comercio, sistemas de comercio automatizados y prueba de estrategias de comercio
MT5 y la velocidad en acción
fxsaber, 2020.09.02 00:02
Había un código MQL5 limpio y reproducible por muchos. La cronología del hilo primero estudia, en lugar de jugar a la teoría de la conspiración, que alguien te necesita tanto que está dispuesto a gastar su tiempo en ti para enlodar.
Estás haciendo un gran trabajo como pavo. Aquí no se ha hablado de ninguna biblioteca en concreto en el hilo porque no es constructivo.
La cuestión es que si alguien se aventura a utilizar librerías compartidas en las que el parámetro from-input no coincide, se va a llevar un frenazo. No se menciona esto en ninguna parte de la Documentación. Al menos algo de este tema te sacaron con pinzas. Y cuando se hizo, empezaron a acusarte de hacer trampa.
Esta característica de MQL debería estar escrita en la rama de Documentación y en la de Características. Ejecute los scripts MQL5 limpios de esta rama en las construcciones correspondientes a las fechas de su creación. Al parecer, se hicieron muchos arreglos a ciegas por si acaso.
Estás haciendo un gran trabajo como indie. Aquí no se mencionaron específicamente las bibliotecas en el hilo, porque no es constructivo.
Porque has hecho todo lo posible por no hablar de tus bibliotecas. En presencia de estas bibliotecas. Con la constante oposición de "el mío es más rápido". Así que has enmascarado hábilmente el autodisparo sacando a relucir el "mira qué lento es".
La cuestión es que si uno se atreve a utilizar conjuntamente bibliotecas en las que el parámetro from-input no es el mismo, obtendrá retrasos. No se menciona esto en ninguna parte de la Documentación. Al menos algo de eso te sacaron con pinzas. Y cuando se hizo, empezaron a acusarte de hacer trampa.
Esta característica de MQL debería estar escrita en la rama de Documentación y en la de Características. Ejecuta los scripts MQL5 limpios de esta rama en las construcciones correspondientes a las fechas de su creación. Al parecer, se hicieron muchos arreglos a ciegas por si acaso.
La documentación de HistorySelect dice claramente:
Cuando se trabaja con grandes volúmenes (y por algo se mostraron miles y decenas de miles de operaciones en el historial), que requieren un acceso atómico/de instantáneas, es necesario comprender su coste.
Sobre todo porque he explicado los detalles técnicos de estos cachés con mucho detalle en este hilo.
¿Has intentado por nada del mundo aleatorizar cada muestra y envenenar el caché lo máximo posible? Por el bien de su posición, ¿hay que disparar por sí mismo?
Porque hiciste todo lo posible para mantener tus bibliotecas en silencio. Por eso has enmascarado hábilmente los fallos autoinfligidos alardeando de "mira qué lento es".
El 99% de los errores se encuentran de esta manera. En primer lugar, el comportamiento extraño se encuentra en el código grande. Entonces la localización encuentra la causa. Estaba más preocupado por los frenos.
función comercial. Los problemas están en casi todas partes.
La documentación de HistorySelect dice explícitamente:
Me pregunto quién habrá visto algo entre líneas en este texto. Personalmente, he entendido (antes de esta rama), que HistoryDealSelect y HistoryOrderSelect deben ser escritos así.
De lo contrario, está garantizado que se produzcan retrasos.
Cuando se trabaja con volúmenes enormes, que requieren acceso atómico/snapshot, hay que entender su coste.
Sobre todo porque en este hilo he explicado los detalles técnicos de estos cachés con mucho detalle.
He ido recogiendo la información necesaria en este hilo.
¿No has intentado por nada del mundo aleatorizar cada muestra y envenenar el caché lo más posible? Por el bien de su posición, ¿hay que disparar por sí mismo?
Puedes ver todo cronológicamente en este hilo. El problema se mostraba originalmente sin ningún tipo de aleatoriedad.
Este hilo es un gran testimonio de cómo se pueden tergiversar las palabras del adversario. Aquí se guardan todas las fuentes y sus resultados.
¿Por qué el terminal no puede simplemente aumentar el caché cuando se solicita de nuevo el historial completo, recuperar y almacenar en caché el rango que falta? Eso parece resolver el problema. Al fin y al cabo, cuando se solicitan bares/boletos, se devuelven paquetes de datos que faltan, por lo que existe un mecanismo para ello.
¿Por qué el terminal no puede simplemente aumentar el caché cuando se solicita de nuevo el historial completo, recuperar y almacenar en caché el rango que falta?
Esto ya se ha hecho.
Pero si entre HistorySelect( 0, INT_MAX ) llama aHistorySelect( other_time, ... ), la caché se reconstruirá a partir de other_time y la siguiente petición deHistorySelect( 0,... ) llevará a una nueva construcción de la caché (será más lenta).
Esto ya se ha hecho.
Pero si entre las llamadas deHistorySelect( 0, INT_MAX ) llamamos aHistorySelect( otro_tiempo, ... ), la caché se reconstruirá a partir de otro_tiempo y la siguiente petición deHistorySelect( 0,... ) llevará a una nueva construcción de la caché (será más lenta).
Si lo has hecho, es bueno, la única cuestión es entonces sobre la conveniencia de trabajar con los datos recibidos, siempre y cuando el caché se construye.
No entendí tan profundamente las operaciones comerciales, pero si el rango de consulta cambia, entonces no hay posibilidad de buscar rápidamente los datos dentro de la historia sin la fuerza bruta completa?
No estoy tan metido en el comercio, pero si el rango de la consulta cambia, entonces no hay manera de buscar rápidamente los datos dentro de la historia sin una enumeración completa?
¿De qué sirven estos conocimientos si no los utilizas?
Ningún problema práctico = ninguna pregunta.
OrderExist y PositionExist son funciones especiales optimizadas que evitan el estúpido bucle de todas las órdenes o posiciones en busca de entradas por símbolo, tipo de transacción y medzhik.
El resultado es una serie de entradas.
Los programas pueden ahorrar mucho dinero utilizando estas funciones. Especialmente cuando se llaman posiciones y órdenes abiertas en masa, constante y repetidamente en bucles de sobregiro.
En el futuro implementaremos funciones más eficaces para acceder a los datos comerciales masivos.
También se reforzará y simplificará drásticamente el lenguaje con una funcionalidad más potente.
" OrderExist y PositionExist" - no se encuentran en la documentación, ¿dónde leer sobre ellos?
Lo más probable es que después de la próxima versión de lanzamiento (ahora en beta)