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
Hablando de intuición. Quiero darles un ejemplo interesante. Mi post, impreso en este hilo https://www.mql5.com/ru/forum/95632/page12hace más de dos años:
1. El concepto de motor gráfico.
2. Concepto de núcleo gráfico.
3. etapas de creación del estudio visual para la plataforma MT.
4. Descripción del mecanismo de creación de la interfaz EA.
Elmotor gráfico es un programa diseñado como indicador. Este programa está diseñado únicamente para la gestión de la interfaz de usuario. Ejecuta un conjunto de funciones básicas:
El motor gráfico se añade a un gráfico como cualquier otro indicador . Incluye el siguiente conjunto de ventanas:
Esto, en principio, es el fin del concepto de motor gráfico. Lo importante es que sin ella el funcionamiento de la interfaz es imposible.
Un motor gráfico es un bloque de información que contiene datos de todos los objetos y ventanas de una interfaz, que se registra en una matriz y se guarda en un archivo.
Este bloque es una representación digital de la interfaz gráfica. El motor gráfico lo carga a petición del usuario. El propio motor gráfico tiene su propio núcleo gráfico interno que garantiza el funcionamiento de sus propias ventanas, y dentro de este núcleo se proporciona espacio libre para la integración de la interfaz de usuario (en forma digital) en él. La integración se realiza en el proceso de carga del núcleo gráfico desde un archivo.
3. La creación de un estudio visual en la plataforma MT, según tengo entendido, se divide en dos etapas:
4. Me gustaría esbozar el mecanismo del proceso de creación de interfaces y levantar ligeramente el velo sobre su tecnología. Explica de dónde viene la facilidad de crear una interfaz a través de un archivo.
Este es el caso: el motor tiene una función especial que crea un núcleo gráfico completo basado en un único archivo con una cantidad mínima de información de carga. La información de arranque en este archivo se explica por sí misma y es legible para las personas. Es fácil de escribir y editar. Por ejemplo, es necesario escribir "_CREATE_NEW_WINDOW" para crear una ventana, y "_CHECKBOX" y el nombre de la casilla de verificación, (el motor reconoce automáticamente el nombre del elemento, como nombre del propio elemento y como nombre de su parámetro).
Esta función se llama "G_CORE_BUILDER()" y construye el núcleo gráfico tomando datos de dos fuentes principales: un archivo de arranque creado por el usuario y la matriz "CONTENT[]" que contiene todos los grupos de objetos estándar incluidos en las plataformas de ventanas y controles. "CONTENT[]" también contiene estados y scripts de objetos. Todo en una sola matriz. En general, el material de origen de "CONTENT[]" + el archivo de carga creado por el usuario es utilizado por "G_CORE_BUILDER()" para construir el núcleo gráfico con el que trabaja el motor.
Es sorprendente lo mucho que NO han cambiado los términos y conceptos en dos años de duro trabajo. Y las funciones y los arrays y las palabras clave son como dice aquí. Todo se ha implementado de acuerdo con este escenario. Y esta tecnología funciona y evoluciona, a pesar deque hace dos años no tenía NINGUNA experiencia en el desarrollo de un lenguaje de marcas.
No llegué a un callejón sin salida, no cambié el concepto, no cambié la dirección. Seguí creando el motor, el núcleo y el lenguaje de marcado exactamente como pretendía en un principio. Y la práctica confirma que el camino que elegí fue el correcto.
Si esto no es una intuición profética, ¿qué es?
Estimados opositores.
Aquí está el código de la secuencia de comandos que:
Resultado:
Mi solución es más de 10 veces más rápida.
Añade a tu solución, el tiempo para guardar el recurso y el tiempo para obtener el recurso en el array usando ResourceReadImage();
En mi solución, no se requiere ni lo primero ni lo segundo.
Mi solución es más de 10 veces más rápida.
Peter, si trabajas con cuerdas, perderás rendimiento en cualquier caso. Por eso sorprende que persigas un rendimiento mítico, aunque originalmente hayas elegido una solución inadecuada para ello: pasar los mensajes a través de una cadena y luego parsear ese mensaje.
Peter, si trabajas con cuerdas, perderás rendimiento en cualquier caso. Así que es sorprendente escuchar que persigues un rendimiento mítico, a pesar de que originalmente elegiste una solución inadecuada para ello: pasar mensajes a través de una cadena y luego analizar ese mensaje.
Vasily, ¿de qué otra forma se pueden transferir datos de todo tipo entre programas?
OnChartEvent() es parcialmente adecuado.
Y por cierto, medir menos de 20 milisegundos, estrictamente hablando no es válido en absoluto, al menos en sistemas con multithreading preventivo. Pero aunque aceptes tu resultado (en general lo admito), sigue sin decirte nada, porque lo que importa son los costes del ciclo completo. Y lo que has medido es sólo una parte.
Necesito una forma universal y la más rápida. Para trabajar en el probador y evitar la cola de eventos OnChartEvent();
La prueba muestra que es 10 veces más lenta la transferencia a través de los recursos. (sin medir el tiempo para guardar el recurso y obtener los datos del mismomediante ResourceReadImage()) .
Mi solución es la mejor opción en las condiciones iniciales.
...Pero aunque aceptes tu resultado (en general lo admito), sigue sin decirte nada, porque lo que importa son los costes del círculo completo. Y lo que has medido es sólo una parte.
Es cierto, pero si se extrapola a más líneas y marchas, mi opción sigue ganando.
Vasiliy, ¿de qué otra forma se pueden transferir datos de todo tipo entre programas?
Mapeo directo de estructuras a través de la unión a la matriz de bytes, compartida para el acceso global. No sé si esto es técnicamente factible, pero si es así, la velocidad será cósmica, porque no tendrás que copiar nada en absoluto.