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 favor, dé un diagrama-código rudimentario para esta idea. A primera vista parece un completo malentendido.
Durante la ejecución de la función OnMain no hay forma de conocer el estado de la cola real actual. La única solución para hacer esto es un programa espía, como se indica en el enlace.
En su forma más simple:
Sólo hay que cambiar el enfoque de los propios cálculos (hacer la vuelta intermedia con la frecuencia que requiera la tarea). Pero si es difícil, considera en el 1er paso que OnMain no existe para ti (mueves el código principal no en OnMain, sino en On2XX), respectivamente, en OnMain no necesitas aprender nada
Se están haciendo muletas en la dirección equivocada:
Deje las funciones OnXXX sólo copiando eventos (parámetros) en la cola y llamando a la función principal OnMain. Mueve todo su código para duplicar las funciones de On2XX. Y llame a estas funciones duplicadas On2XX desde el OnMain en la secuencia que necesite, pasándoles a su vez los datos de las colas como parámetros.
A continuación, ejecute las mediciones y mostrar la ganancia de velocidad, y entonces usted puede sugerir para complementar MQL con la funcionalidad adecuada. Pero, ¿por qué añadir, si ya lo has hecho todo tú aquí y ahora?
No es eso lo que estás escribiendo.
El problema es que la funcionalidad de rellenar los campos en las variables de entrada de la función "OntaredeTransaction" no se corresponde con la descripción dada en la Ayuda, para peor:
es decir, muchos campos no se rellenan en las llamadas e incluso en la llamada final de TRADE_TRANSACTION_HISTORY_ADD.
Por lo tanto, todos los comerciantes están agonizando aquí para determinar de alguna manera estos parámetros que faltan en el momento de la llegada.
Hubo muchas discusiones aquí, basta con hacer una búsqueda en el foro - la pobre funcionalidad de "OntaredeTransaction" causa gastos adicionales tanto en tiempo como "carga" a los comerciantes con el tiempo extra dedicado al desarrollo de un código que funcione adecuadamente (es decir, enormes pérdidas de tiempo y una ineficacia colosal a nivel de la comunidad).
Las respuestas actuales de los desarrolladores como "Si tiene un símbolo de ejecución de mercado, tendrá un valor de precio cero; debería ser así" (Enlace).(Link) - esto es UNNORMAL, una vez más -
falta de valores exhaustivos en la última llamada a la función conduce a un montón de trabajo extra.
HistorySelect.
Esta es una característica increíblemente cara. Y, por desgracia, ninguna cantidad de caché puede hacer que su velocidad sea aceptable ahora.
Por ejemplo, en los EA de campo de batalla es importante trabajar con datos reales. En particular, que los ticks de Market Watch y CopyTicks no estén desactualizados si es posible.
Para ello, existen mecanismos no muy buenos, pero obligados, para comprobar la pertinencia de los datos de precios actuales. Una parte de este mecanismo consiste en detectar situaciones en las que una operación sobre un símbolo ha pasado más tarde del último tick. Esto no ocurre raramente, por lo que es importante saber si la garrapata actual está actualizada o no.
Para esta detección, es necesario poder acceder al historial de ofertas recientes. Se hace utilizando el HistorySelect de la siguiente manera esquemática.
Desgraciadamente, esa llamada de HistorySelect tarda entre 5 y 30 milisegundos (lo he medido yo mismo en Release-EX5). Cuando el Asesor Experto hace varias de estas actualizaciones en OnTick (debería hacerse después de cualquier pausa, por ejemplo, después de cada OrderSend), entonces todo se vuelve insanamente caro/largo. HistorySelect puede consumir colectivamente varios segundos en un solo OnTick.
Queridos desarrolladores, ¿por qué es tan caro? Esta función puede ejecutarse instantáneamente con una implementación adecuada.
¿Tienes pruebas de que "una llamada a HistorySelect dura entre 5 y 30 milisegundos"?
Si he entendido bien tu idea, el código de prueba debería ser así:
Así es como funcionan las consultas 100000:
¿Tienes pruebas de que "una llamada a HistorySelect dura entre 5 y 30 milisegundos"?
Si he entendido bien lo que dices, el código de prueba debería ser así:
Así es como funcionan las 100.000 consultas:
¿Tienes pruebas de que "una llamada a HistorySelect dura entre 5 y 30 milisegundos"?
Si he entendido bien lo que dices, el código de prueba debería ser así:
Así es como funcionan las 100.000 consultas:
Ejecutando su script.
Lanza otra secuencia de comandos.
Cuenta de batalla normal. No es HFT.
Por cierto, tu script mostró que HistorySelect recalcula todo cada vez. Y los parámetros de entrada no cambiaron, la tabla del historial no se actualizó, no se llamaron otras funciones de HistorySelect.
Ejecutando su script.
Entonces se necesitan detalles.
Mi prueba se ejecutaba en el no más rápido "Intel Xeon E5-2630 v4 @ 2.20GHz" con muchos otros procesos en el fondo.
El historial de mi cuenta de prueba muestra 31315 órdenes más o menos uniformes desde 2009, incluyendo 8 órdenes para hoy.
Tal vez, usted tenía algún script o Asesor Experto corriendo al mismo tiempo causando una carga drástica de las bases de datos del terminal. Pruébalo en un terminal "limpio".
Prueba más informativa:
Tres carreras:
Entonces se necesitan detalles.
Mi prueba se ejecutaba en el no más rápido "Intel Xeon E5-2630 v4 @ 2.20GHz" con muchos otros procesos en el fondo.
La cuenta de prueba tenía 31315 órdenes en su historia más o menos uniforme desde 2009, incluyendo 8 órdenes para hoy.
Tal vez, usted tenía algún script o Asesor Experto corriendo al mismo tiempo causando una carga drástica de las bases de datos del terminal. Pruébalo en un terminal "limpio".
Terminal vacía en la misma cuenta y máquina.
En otras cuentas y terminales la misma imagen. Configuración.
Pido a los lectores que den sus resultados de este guión.
Una prueba más informativa:
Tres salidas:
Terminal vacía 2460.
ZZY Corre con la cuenta vacía.
La velocidad parece estar fuertemente influenciada por el número de operaciones, no de órdenes.
Terminal vacía en la misma cuenta y máquina.
En otras cuentas y terminales el mismo patrón. Configuración.
Pido a los lectores que citen los resultados de este guión.
No demuestra nada, pero el hecho de que con cada nueva ejecución (en un símbolo diferente), el tiempo aumenta - es alarmante...
Necesidad de ejecutar en una cuenta con un largo historial de operaciones.