MT5 y la velocidad en acción - página 17
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
Tenga en cuenta que HistorySelect realiza una instantánea física del historial seleccionado en la caché local del EA, para que pueda recorrerlo sin miedo. Sin esto se pueden obtener efectos muy desagradables, ya que el historial de la cuenta se actualiza/sincroniza de forma asíncrona. Por no hablar del hecho de que el propio usuario puede cambiar manualmente la profundidad del historial desde la interfaz.
De ahí los costes de las copias. Más aún si se intenta forzar deliberadamente la copia de este historial en la caché simultáneamente desde varios hilos.
Ya hemos optimizado mucho en las operaciones de muestreo y ahora pensamos en la actualización óptima de la caché, cuando en realidad el 99% de las muestras serán completamente inútiles y se saltarán sobre la marcha.
Es decir, a menos que se aleatoricen específicamente los límites de muestreo, la caché mostrará aciertos cercanos al 100%.
Lo más probable es que la próxima semana ya haya una solución efectiva.
Tenga en cuenta que HistorySelect realiza una instantánea física del historial seleccionado en la caché local del EA, para que pueda recorrerlo sin miedo. Sin esto se pueden obtener efectos muy desagradables, ya que el historial de la cuenta se actualiza/sincroniza de forma asíncrona. Eso sin contar con que el propio usuario puede cambiar manualmente la profundidad del historial desde la interfaz.
Hay una tabla de pedidos y una tabla de tratos. ¿Por qué necesitaríamos hacer snaps físicos, cuando conocemos los cuatro índices en el momento de la llamada a HistorySelect?
Por eso los costes de las copias son tan elevados. Especialmente si tratamos específicamente con la copia forzada simultánea de este historial en la caché desde múltiples hilos.
Ya hemos optimizado mucho en las operaciones de muestreo y ahora estamos pensando en la actualización óptima de la caché, cuando en realidad el 99% de las muestras serán completamente inútiles y se saltarán sobre la marcha.
Es decir, a menos que aleatorice específicamente los límites de muestreo, la caché mostrará aciertos cercanos al 100%.
Lo más probable es que la próxima semana ya haya una solución efectiva.
HistoryDealSelect y HistoryOrderSelect ahora destruyen las muestras correspondientes. ¿Por qué no hay, como en MT4, acceso a ambas tablas por índices? Introducir nuevas funcionalidades.
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Bichos, errores, preguntas
fxsaber, 2020.08.20 11:28
Nuevas funciones internas.Los índices lo piden. No entiendo por qué debo saber el número de operaciones en mi cuenta a través de un lugar.
Y estas tablas pueden cambiar en cualquier momento. También lo pueden hacer los registros individuales en ellos.
Nadie puede garantizar su inmutabilidad debido a las operaciones asíncronas, los procesos de sincronización y los modos de profundidad manuales establecidos por los usuarios.
Como escribí anteriormente, aplicaremos técnicas inteligentes de almacenamiento en caché, que reducirán el coste de las funciones Select a cero. A menos que, por supuesto, se aleatoricen específicamente los límites de muestreo. La última fecha puede cambiarse y no invalidará la caché si siempre está en el futuro/última vez. Las transacciones recientes se añadirán a la caché con moderación.
En MT4 funciona igual, sólo que la creación de la caché está oculta. En cada OnTick/OnStart de MT4, el terminal crea automáticamente y con moderación una instantánea del entorno del mercado para cada EA.
Por lo tanto, no se puede evaluar la verdadera latencia de la preparación de datos a partir del código MQL4. Afortunadamente, en MT4 los datos son pequeños y sencillos.
En MT5 renunciamos a los costes de la creación automática del entorno de mercado para reducir los retrasos y no hacer un trabajo innecesario. En cambio, hemos dado el control total de los costes a los desarrolladores de robots, que pueden solicitar exactamente lo que necesitan.
Tenga en cuenta que el tamaño del entorno de mercado en MT5 es enorme en comparación con MT4 - simplemente no puede ser replicado.
Con sus pruebas ha aprovechado una de estas costosas muestras.
Lo arreglaremos, es nuestro interés.
Y estas tablas pueden cambiar en cualquier momento. También lo pueden hacer los registros individuales en ellos.
Nadie puede garantizar su inmutabilidad debido a las operaciones asíncronas, los procesos de sincronización y los modos de profundidad manuales establecidos por los usuarios.
¿Está diciendo que antes de la última operación, puede aparecer otra operación en el historial de operaciones? Si un oficio ha cambiado, otro. Pero meter la cuña dentro de una lista ya existente, no lo he notado.
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.
¿Está diciendo que puede haber otra operación en el historial de operaciones antes de la última operación? Si un acuerdo ha cambiado, otro. Pero meter la cuña dentro de una lista ya existente, no lo he notado.
En teoría, sí.
No te olvides de los procesos de sincronización. Un gran número de procesos de la plataforma son asíncronos.
Por ejemplo, la integración de una pasarela con una bolsa o un proveedor de liquidez puede enviar informes de transacciones con retrasos de segundos o incluso minutos. A menudo la api no proporciona acceso al historial para la conciliación en absoluto, sino que proporciona generadores de informes lentos y sin ritmo.
En la apertura del mercado, o debido a una reconexión inesperada de la puerta de enlace, los informes pueden retrasarse. Se replican en el historial del servidor y se envían inmediatamente de forma asíncrona a los terminales. Gracias a la clasificación por fecha, se insertan en los lugares adecuados, y mientras tanto puede abrir nuevas operaciones.
La mayoría de las API de integración son tan analfabetas y disfuncionales que casi hacen imposible hacer pasarelas garantizadas. Aunque existe la opinión de que esto es producto de un sabotaje deliberado por parte de sus desarrolladores.
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.
Renat, una gran petición para tener acceso a las cotizaciones fuera de TERMINAL_MAXBARS cuando se utilizan las funciones Copy... Por lo menos, el plazo de un minuto. También puede hacer una función separada para esto.
Pero para tener acceso a estos datos hay que poner siempre TERMINAL_MAXBARS en ilimitado (además, sobrecarga el terminal), lo cual es muy inconveniente porque no se necesita ilimitado para todos los símbolos.
Según tengo entendido, si se copian todas las barras del periodo MN1, se seguirán descargando todas las barras M1, pero no se podrá acceder a ellas.
Por supuesto, se pueden descargar todos los ticks, ya que no están sujetos a esta restricción, pero lleva más tiempo y, por desgracia, los ticks no siempre coinciden con todo el historial de minutos.
Renat, una gran petición para tener acceso a las cotizaciones fuera de TERMINAL_MAXBARS cuando se utilizan las funciones Copy... Por lo menos, el plazo de un minuto. También puede hacer una función separada para esto.
Pero para tener acceso a estos datos hay que poner siempre TERMINAL_MAXBARS en ilimitado (además, sobrecarga el terminal), lo cual es muy inconveniente porque no se necesita ilimitado para todos los símbolos.
Al fin y al cabo, según tengo entendido, si se copian todas las pequeñas barras del periodo MN1, todas las barras M1 se descargarán de todos modos, pero no hay acceso a ellas.
Por supuesto, se pueden descargar todos los ticks porque no están sujetos a esta restricción, pero lleva más tiempo y, por desgracia, los ticks no siempre coinciden con todo el historial de minutos.
No, el historial fuera de estos límites no se recoge ni se comprueba la sincronización. Además, no hay lugar para almacenarlas (no construiremos cachés invisibles adicionales), no escalaremos el disco en modos no económicos y no construiremos muletas.
En realidad, es una mala idea, ya que los desarrolladores comenzarán inmediatamente a escribir algoritmos absolutamente ineficientes, aconsejarán a los operadores que "pongan 5000 o mejor 1000 barras" y nos acusarán de lentitud e ineficacia.
Hemos permitido a propósito controlar la cantidad de recursos asignados a los gráficos. Es de 64 bits y la memoria es barata ahora - utiliza los ajustes apropiados dentro de las reglas y la arquitectura.
No vamos a cambiar este comportamiento.
No, el historial que se encuentra fuera de estos límites no se levanta ni se comprueba la sincronización. Además, no hay lugar para almacenarlas (no construiremos cachés invisibles adicionales) y no escalaremos el disco en modos no económicos.
De hecho, es una idea perjudicial, ya que los desarrolladores comenzarán inmediatamente a escribir algoritmos absolutamente ineficientes y aconsejarán a los operadores "poner 5000 o mejor 1000 barras" y nos acusarán de lentitud e ineficacia.
Hemos permitido a propósito controlar la cantidad de recursos asignados a los gráficos. Es de 64 bits y la memoria es barata ahora - utiliza los ajustes apropiados dentro de las reglas y la arquitectura.
No vamos a cambiar este comportamiento.
Bien. Lo tengo. Gracias. Tachado.
Aunque, por supuesto, me gustaría discutir sobre la deseconomía. Tendré que dejar ilimitados y como resultado todos los abiertos (por ejemplo tengo 14 gráficos en este momento) mantendrán todo el historial, aunque sólo necesito 5000 para la mayoría de ellos. Que por el contrario será más antieconómico.
Además, no necesito que estos datos se almacenen. Yo me encargaré del almacenamiento. He iniciado la carga de todas las barras de minutos, las he metido en un array y ya no lo necesito y todas las cachas se pueden borrar si su tamaño excede el TERMINAL_MAXBARS. Así que tal vez para eso sea una función separada que no almacene cachés.
Aunque, por supuesto, estoy de acuerdo en que las manos traviesas pueden suspender el sistema con esas cargas periódicas.
¿Sólo tienes dos estados 5000 y uno ilimitado?
Tú eres el cerebro de tu propia felicidad.