Mon approche. Le noyau est le moteur. - page 87
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
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.
Chers opposants.
Voici le code du script qui :
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 :
MT5 :
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 ?
Vous devriez au moins lire l'aide
Chers opposants.
Voici le code du script qui :
Résultat :
Lisez attentivement et concluez : https://docs.mql4.com/ru/basis/types/stringconst
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.
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 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.
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.
...
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...
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.