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
s.s. En concreto, sobre el tema del almacenamiento de cadenas en objetos MT, hay un fallo extraño. Si empiezas a comprimir los datos y utilizas caracteres no impresos en el nombre del objeto, en algunos casos no podrás acceder a ese objeto. Es probable que el fallo siga existiendo porque es muy específico y no hay mucha gente que lo conozca, pero aun así puede que te tropieces con él.
Ya veo. Sólo la práctica ayudará a resolverlo definitivamente.
Estimados opositores.
Aquí está el código de la secuencia de comandos que:
Resultado:
Peter, estás probando la cosa equivocada en el lugar equivocado. Lo que estás probando debería tener más o menos la misma velocidad en términos de lógica de cadena.
Has malinterpretado completamente mi mensaje.
Mi mensaje era que debías dejar de usar cadenas para pasar double,long,time,int etc. Y si necesitas pasar texto, entonces traduce una cadena de texto a un array uchar. Y todos los datos mezclados de diferentes tipos a través de estructuras de datos de unión o matrices de estas estructuras, convertidas a matrices uint a través de la unión, deben pasar a través de los recursos, y en el lado receptor estas matrices uint deben ser convertidas de nuevo a través de la unión a las estructuras originales. Créeme, Peter, los tangas son muy lentos, deberías evitarlos siempre que sea posible. La cadena es necesaria sólo para la salida de texto e impresión.
Y en tu ejemplo tienes la noción de medir el rendimiento completamente equivocada.
Especialmente a través de la propiedad OBJPROP_TEXT puede pasar una cadena con un tamaño máximo de 63 bytes. Esto no es nada.
Aunque tu ejemplo no tiene ningún sentido, pero lo he modificado a algo más correcto puramente con fines de demostración y esto es lo que he obtenido al copiar 1000 cadenas diferentes con tamaño 63 bytes:
Se adjunta el código del script. Funciona tanto en MT4 como en MT5
MT4:
MT5:
Parece que MT5 es asíncrono, por lo que su método es 100 veces más lento y no es adecuado para MT5 en absoluto. Deberías centrarte cada vez más en MT5
¿Y qué es?
Al menos deberías leer la Ayuda
Estimados opositores.
Aquí está el código de la secuencia de comandos que:
Resultado:
Lea atentamente y concluya: https://docs.mql4.com/ru/basis/types/stringconst
no están de acuerdo. Necesitamos el array uchar para la cadena como intermedio. Y no hay conversión, sólo se copian los bytes.
No estoy de acuerdo. Necesitamos un array uchar para la cadena como intermedio. Y no hay conversión, sólo copia de bytes.
Intente utilizar caracteres cirílicos. Y comparar los códigos de caracteres en la matriz uchar y en la cadena, la cadena es como la matriz ushort.
Sé lo que es unicode. Pero en nuestro caso necesitamos el array uchar sólo para obtener el array uint a través de la unión para pasarlo más allá a través del recurso y al volver la cadena de recuperación de la cadena. No habrá pérdidas. Y en este caso no necesitamos extraer caracteres del array uchar.
La codificación puede cambiarse y es no unicode por defecto.
Peter, estás probando la cosa equivocada en el lugar equivocado. Lo que estás probando debería tener más o menos la misma velocidad en términos de lógica de cadena.
Nikolai, con el debido respeto, eso son palabras vacías para nada. He medido y adjuntado un guión. "La forma correcta, la forma incorrecta...", "debería tener aproximadamente la misma velocidad en términos de lógica de cuerdas"... Sólo palabras.
Nikolai Semko:
...
Has malinterpretado completamente mi mensaje.
Mi mensaje era que debías dejar de usar cadenas para pasar double, long,time, int etc. Y si necesitas pasar texto, entonces convierte una cadena de texto a un array uchar. Y todos los datos mixtos de diferentes tipos a través de estructuras de datos de unión o matrices de estas estructuras, convertidas a matrices uint a través de la unión, deben pasar a través de los recursos, y en el lado receptor estas matrices uint deben ser convertidas de nuevo a través de la unión a las estructuras originales. Créeme, Peter, los tangas son muy lentos, deberías evitarlos siempre que sea posible. La cadena es necesaria sólo para la salida de texto e impresión.
Ese es exactamente su mensaje que he entendido perfectamente. Y ESTÁ MAL.
¿Por qué? - Porque habría que complicar MUCHO el sistema de trabajo con los parámetros de control. La arquitectura de almacenamiento, paso y gestión de parámetros se volverá MUCHO más complicada y confusa, lo que provocará muchos problemas y una ralentización general.
No entiendes la arquitectura interna. No sabe cómo interactúan los programas, gestiona los valores de los parámetros según su tipo y propiedades. Lo que propones haría las cosas mucho más complicadas y confusas. Y no resolverá el problema de la comunicación. Seguirá siendo una muleta.
...
Además, puede pasar una cadena con un tamaño máximo de 63 bytes a través de la propiedad OBJPROP_TEXT. Eso no es nada.
Aunque tu ejemplo no tiene ningún sentido, lo he rehecho para que sea más correcto, sólo para demostrarlo, y esto es lo que he obtenido al copiar 1000 cadenas diferentes de tamaño 63 bytes:
...
Puede pasar una cadena de 64 caracteres por la descripción de un objeto MT. Es suficiente. Necesito - 20-30 líneas para transferir datos de tablas grandes. Sin tablas grandes, necesito 2-3 líneas como máximo.
Estoy interesado en MT4 en este momento.
MT5 está en constante desarrollo. Los desarrolladores pueden simplemente añadir la memoria común de los programas de MT (para no tener que complicarse con los recursos) y la pregunta será eliminada.
Nikolai Semko:
...
Mi mensaje era que deberíamos dejar de usar cadenas para pasar double,long,time,int etc.
...
¿Cómo se transfiere double,long,time,int etc...? ???
De todos modos, tenemos que convertirlo en cadena y luego en char para escribirlo en el recurso.
¿O sugieres usar lparam,dparam ?
Es decir, sobrecargar la cola de eventos...
Además, en tus mediciones, olvidaste añadir el tiempo de guardar y leer el recurso...
Así que, aunque escribas 1000 líneas (lo que realmente es mejor pasar por el recurso), no ganas en velocidad, debido al coste de guardar y recuperar del recurso.