Mi enfoque. El núcleo es el motor. - página 87

 
Vasiliy Sokolov:
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.

 
Реter Konow:

Estimados opositores.

Aquí está el código de la secuencia de comandos que:

  1. Mide el tiempo de transferencia de una cadena a una matriz Char, para pasar la cadena a otro programa a través de un recurso y el tiempo de recuperación de una cadena de una matriz Char para la posterior división y recuperación de información.
  2. Mide el tiempo para escribir la cadena en la descripción del objeto MT y el tiempo para recuperar la cadena de la descripción del objeto MT, para la posterior división y recuperación de la información.

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:

2018.12.19 00:50:14.542 TestStringVsCharArray NZDUSD,Weekly: время через свойство объекта:      2309 правильность копирования - true
2018.12.19 00:50:14.542 TestStringVsCharArray NZDUSD,Weekly: время через uchar массив:          1882 правильность копирования - true

MT5:

2018.12.19 00:32:30.857 TestStringVsCharArray (NZDUSD,M1)       время через свойство объекта:      32811 правильность копирования - true
2018.12.19 00:33:00.678 TestStringVsCharArray (NZDUSD,M1)       время через uchar массив:          364   правильность копирования - true

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?

StringToCharArray(qwerty,Arr,0,WHOLE_ARRAY);

Al menos deberías leer la Ayuda

Archivos adjuntos:
 
Реter Konow:

Estimados opositores.

Aquí está el código de la secuencia de comandos que:

  1. Mide el tiempo de transferencia de una cadena a una matriz Char, para pasar la cadena a otro programa a través de un recurso y el tiempo de recuperación de una cadena de una matriz Char para la posterior división y recuperación de información.
  2. Mide el tiempo para escribir la cadena en la descripción del objeto MT y el tiempo para recuperar la cadena de la descripción del objeto MT, para la posterior división y recuperación de la información.

Resultado:


Lea atentamente y concluya: https://docs.mql4.com/ru/basis/types/stringconst
Para ayudar a las conclusiones:
1. Se asignan 2 bytes para cada carácter de la cadena, codificación Unicode. No se aprovecha al máximo la capacidad de las cuerdas.
2. Cuando se utiliza la función CharArrayToString (y la inversa), se realiza la conversión según la codificación de los caracteres en la matriz uchar, lo que también consume tiempo de CPU. Utilice ShortArrayToString(y viceversa).
Pruébalo, pero ten en cuenta que en Unicode la cadena debe terminar en cero.
 
Aliaksandr Hryshyn:
Lea atentamente y concluya: https://docs.mql4.com/ru/basis/types/stringconst
Ayudaré con las conclusiones:
1. Se asignan 2 bytes para cada carácter de la cadena, codificación Unicode. No se aprovecha al máximo la capacidad de las cuerdas.
2. Cuando se utiliza la función CharArrayToString (y la inversa), se realiza la conversión según la codificación de los caracteres en la matriz uchar, lo que también consume tiempo de CPU. Utilice ShortArrayToString(y viceversa).
Pruébalo, pero ten en cuenta que la cadena debe terminar con null en Unicode.

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.

 
Nikolai Semko:

No estoy de acuerdo. Necesitamos un array uchar para la cadena como intermedio. Y no hay conversión, sólo copia de bytes.

Intenta pasar los caracteres cirílicos. Y compara los códigos de caracteres en el array uchar y en la cadena, la cadena se pasa como un array ushort.
 
Aliaksandr Hryshyn:
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.

 
Nikolai Semko:

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.

Nikolai Semko:

...

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...

 
Реter Konow:


Qué pena. Me salgo del tema.
Jardín de infancia, segundo trimestre.
Me aburres, Peter, con tu analfabetismo e ignorancia y tu prepotencia y derecho.
 
Nikolai Semko:


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.

Razón de la queja: