Mon approche. Le noyau est le moteur. - page 87

 
Vasiliy Sokolov:
s.w. En ce qui concerne spécifiquement le stockage des chaînes de caractères dans les objets MT, il y a un problème étrange. Si vous commencez à compresser les données et que vous utilisez des caractères non imprimés dans le nom de l'objet, dans certains cas, vous ne pourrez pas accéder à cet objet. Le problème est probablement toujours présent car il est très spécifique et peu de gens le connaissent, mais vous pouvez néanmoins tomber dessus.

Je vois. Seule la pratique permettra d'y voir clair.

 
Реter Konow:

Chers opposants.

Voici le code du script qui :

  1. Mesure le temps de transfert d'une chaîne de caractères vers un tableau Char, pour transmettre la chaîne à un autre programme via une ressource et le temps de récupération d'une chaîne de caractères à partir d'un tableau Char pour le fractionnement et la récupération ultérieurs d'informations.
  2. Mesure le temps d'écriture de la chaîne dans la description de l'objet MT et le temps d'extraction de la chaîne de la description de l'objet MT, pour le fractionnement et l'extraction ultérieurs de l'information.

Résultat :


Peter, tu testes la mauvaise chose au mauvais endroit. Ce que vous testez devrait avoir à peu près la même vitesse en termes de logique de chaîne.

Vous avez complètement mal compris mon message.

Mon message était que vous devriez arrêter d'utiliser des chaînes de caractères pour passer des doubles, des longs, des temps, des int, etc. Et si vous avez besoin de passer du texte, alors traduisez une chaîne de texte en tableau uchar. Et toutes les données mélangées de différents types via des structures de données d'union ou des tableaux de ces structures, convertis en tableaux d'uint via l'union, doivent être transmises par des ressources, et du côté de la réception, ces tableaux d'uint doivent être reconvertis via l'union dans les structures d'origine. Crois-moi, Peter, les strings sont très lents, tu devrais toujours les éviter dans la mesure du possible. String n'est nécessaire que pour le texte et la sortie imprimée.

Et dans votre exemple, vous vous trompez complètement sur la notion de mesure des performances.

En particulier, la propriété OBJPROP_TEXT permet de transmettre une chaîne de caractères d'une taille maximale de 63 octets. Ce n'est rien.

Bien que votre exemple n'ait aucun sens, je l'ai modifié en quelque chose de plus correct dans un but purement démonstratif et voici ce que j'ai obtenu en copiant 1000 chaînes différentes de taille 63 octets :

Le code du script est joint. Il fonctionne à la fois sur MT4 et 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

Il semble que MT5 soit asynchrone, donc votre méthode est 100 fois plus lente et ne convient pas du tout à MT5. Vous devriez vous concentrer de plus en plus sur MT5

Et qu'est-ce que c'est ?

StringToCharArray(qwerty,Arr,0,WHOLE_ARRAY);

Vous devriez au moins lire l'aide

Dossiers :
 
Реter Konow:

Chers opposants.

Voici le code du script qui :

  1. Mesure le temps de transfert d'une chaîne de caractères vers un tableau Char, pour transmettre la chaîne à un autre programme via une ressource et le temps de récupération d'une chaîne de caractères à partir d'un tableau Char pour le fractionnement et la récupération ultérieurs d'informations.
  2. Mesure le temps d'écriture de la chaîne dans la description de l'objet MT et le temps d'extraction de la chaîne de la description de l'objet MT, pour le fractionnement et l'extraction ultérieurs de l'information.

Résultat :


Lisez attentivement et concluez : https://docs.mql4.com/ru/basis/types/stringconst
Pour aider avec les conclusions :
1. 2 octets sont alloués pour chaque caractère de la chaîne, encodage Unicode. Pas d'utilisation complète de la capacité des cordes.
2. Lors de l'utilisation de la fonction CharArrayToString (et inversement), la conversion selon l'encodage des caractères dans le tableau uchar est effectuée, ce qui consomme également du temps CPU. Utilisez ShortArrayToString (et vice versa).
Essayez-le, mais notez qu'en Unicode la chaîne doit se terminer par un zéro.
 
Aliaksandr Hryshyn:
Lisez attentivement et concluez : https://docs.mql4.com/ru/basis/types/stringconst
Je vous aiderai pour les conclusions :
1. 2 octets sont alloués pour chaque caractère de la chaîne, encodage Unicode. Pas d'utilisation complète de la capacité des cordes.
2. Lors de l'utilisation de la fonction CharArrayToString (et vice versa) , la conversion selon l'encodage des caractères dans le tableau uchar est effectuée, ce qui consomme également du temps CPU. Utilisez ShortArrayToString (et vice versa).
Essayez-le, mais notez que la chaîne doit se terminer par null en Unicode.

ne sont pas d'accord. Nous avons besoin d'un tableau uchar pour la chaîne de caractères comme intermédiaire. Et il n'y a pas de conversion, juste une copie d'octets.

 
Nikolai Semko:

Je ne suis pas d'accord. Nous avons besoin d'un tableau uchar pour la chaîne de caractères comme intermédiaire. Et il n'y a pas de conversion, juste une copie d'octets.

Essayez de passer les caractères cyrilliques. Et comparer les codes de caractères dans le tableau uchar et dans la chaîne, la chaîne est passée comme un tableau ushort.
 
Aliaksandr Hryshyn:
Essayez d'utiliser les caractères cyrilliques. Et comparez les codes de caractères dans le tableau uchar et dans la chaîne, la chaîne est comme un tableau ushort.

Je sais ce qu'est l'unicode. Mais dans notre cas, nous n'avons besoin d'un tableau uchar que pour obtenir un tableau uint par le biais de l'union afin de le faire passer plus loin dans la ressource et de récupérer la chaîne de caractères. Il n'y aura pas de pertes. Et dans ce cas, nous n'avons pas besoin d'extraire les caractères du tableau uchar.

L'encodage peut être modifié et est non-unicode par défaut.

 
Nikolai Semko:

Peter, tu testes la mauvaise chose au mauvais endroit. Ce que vous testez devrait avoir à peu près la même vitesse en termes de logique de chaîne.

Nikolaï, avec tout le respect que je vous dois, ce sont des paroles en l'air pour rien. J'ai mesuré et joint un script. "La bonne façon, la mauvaise façon...", "devrait avoir approximativement la même vitesse en termes de logique de chaîne"... Juste des mots.

Nikolai Semko:

...

Vous avez complètement mal compris mon message.

Mon message était que vous devriez cesser d'utiliser des chaînes de caractères pour transmettre des données de type double, long, time, int, etc. Et si vous avez besoin de passer du texte, alors convertissez une chaîne de texte en tableau uchar. Et toutes les données mélangées de différents types via des structures de données d'union ou des tableaux de ces structures, convertis en tableaux d'uint via l'union, doivent être transmises par des ressources, et du côté de la réception, ces tableaux d'uint doivent être reconvertis via l'union dans les structures d'origine. Crois-moi, Peter, les strings sont très lents, tu devrais toujours les éviter dans la mesure du possible. String n'est nécessaire que pour le texte et la sortie imprimée.

C'est exactement votre message que j'ai parfaitement compris. ET C'EST FAUX.

Pourquoi ? - Parce que cela compliquerait énormément le système de travail avec les paramètres de contrôle. L'architecture de stockage, de passage et de gestion des paramètres deviendra BEAUCOUP plus compliquée et confuse, ce qui entraînera de nombreux problèmes et un ralentissement général.

Vous ne comprenez pas l'architecture interne. Vous ne savez pas comment les programmes interagissent, gèrent les valeurs des paramètres en fonction de leur type et de leurs propriétés. Ce que vous proposez rendrait les choses beaucoup plus compliquées et confuses. Et ça ne résoudra pas le problème de la communication. Elle restera toujours une béquille.

Nikolai Semko:

...

De plus, vous pouvez transmettre une chaîne de caractères d'une taille maximale de 63 octets via la propriété OBJPROP_TEXT. Ce n'est rien.

Bien que votre exemple n'ait aucun sens, je l'ai retravaillé en quelque chose de plus correct à des fins de démonstration uniquement, et voici ce que j'ai obtenu en copiant 1000 chaînes différentes d'une taille de 63 octets :

...

Vous pouvez passer une chaîne de 64 caractères dans la description d'un objet MT. C'est suffisant. J'ai besoin de 20 à 30 lignes pour transférer les données de grands tableaux. Sans grandes tables, j'ai besoin de 2-3 lignes au maximum.

Je m'intéresse à MT4 pour le moment.

MT5 se développe en permanence. Les développeurs peuvent simplement ajouter la mémoire commune des programmes de TA (afin de ne pas avoir à s'occuper des ressources) et la question sera supprimée.

 

Nikolai Semko:

...

Mon message était que nous devrions arrêter d'utiliser des chaînes de caractères pour passer des doubles, des longs, des temps, des int, etc.

...

Comment transférer un double, un long, un temps, un int etc... ? ? ??

Nous devons tout de même le convertir en string puis en char pour l'écrire dans la ressource.

Ou suggérez-vous d'utiliser lparam, dparam ?

C'est-à-dire, surcharger la file d'attente des événements...

 
Реter Konow:


C'est dommage. Je m'éloigne du sujet.
Maternelle, deuxième trimestre.
Vous m'ennuyez, Peter, avec votre analphabétisme et votre ignorance et votre sens exagéré de la suffisance et des droits.
 
Nikolai Semko:


De plus, dans vos mesures, vous avez oublié d'ajouter le temps de sauvegarde et de lecture de la ressource...

Ainsi, même si vous écrivez 1000 lignes (ce qui est vraiment mieux de passer par la ressource), vous ne gagnez pas en vitesse, en raison du coût de la sauvegarde et de la récupération de la ressource.