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

Nouveau commentaire
 
Реter Konow:

Une autre question sérieuse.

Je ne l'ai pas essayé moi-même, mais on peut douter de l'efficacité d'un échange rapide via les ressources.

Échange rapide, - 16 millisecondes dans les deux sens en permanence.

Le lecteur ne va-t-il pas être surchargé ?

Vous tombez dans le "péché d'optimisation prématurée". :-)

Faites une classe (ou un ensemble de fonctions, si GSE ne vous séduit pas) d'échange de données - si dans des projets réels, cela prend du retard, alors vous réfléchirez aux options. Et pendant ce temps, vous serez occupé par des tests insensés pendant encore six mois.

PS : au fait, avez-vous fait quelque chose pour présenter le projet au public ? ou êtes-vous juste en train de gratter votre ego sur le forum traditionnellement :-)

 
Artyom Trishkin:

Le commentaire du graphique a une taille limitée. Ou pas ? Je suis tombé dessus par hasard.

Je pense qu'il y a des limites. Pour ma part, je ne transmets les ticks MqlTick à EventChartCustom que par le biais de chaînes, car la file d'attente des événements enregistre la séquence des ticks. C'est terriblement pratique.

 
Реter Konow:

C'est-à-dire que vous pouvez traduire un tableau de chaînes de caractères en uint par le biais de l'union ?

Je ne me souviens plus comment c'est implémenté, mais je peux traduire non seulement des tableaux de chaînes de caractères, mais aussi d'autres types de données en n'importe quel type (même dans MqlTick). Le code sera le même.

Et c'est plus rapide que d'utiliserStringToChar() ?

Je ne sais pas. Essayez de convertir MqlTick en chaîne de caractères en utilisant votre méthode, puis en uint via StringToChar. Et vice versa, bien sûr. Mesurez et comparez.

Si vous le pouvez, donnez un petit exemple simple. Je n'arrive pas à comprendre le sens de votre code.

#include <TypeToBytes.mqh> // https://www.mql5.com/ru/code/16280

void OnStart()
{    
  string Str[] = {"123", "Hello World!", "Peter Konow"};

  CONTAINER<uint> Container; // Создаем контейнер - все будет храниться в массиве простого типа (в примере выбран uint)    
  Container[0] = Str;        // Записали в контейнер строковый массив
  
  CONTAINER<uint> Container2;                 // Создаем контейнер-получатель  
  ArrayCopy(Container2.Data, Container.Data); // Скопировали в него ТОЛЬКО содержимое uint массива

  string Str2[];
  Container2[0].Get(Str2); // Получили данные в исходном виде
  ArrayPrint(Str2);
}
 
fxsaber:

Je pense qu'il y a des limites. Pour ma part, je ne transmets les ticks MqlTick à EventChartCustom que par le biais de chaînes, car la file d'attente des événements enregistre la séquence des ticks. C'est vraiment pratique.

S'il s'agit de petits messages (jusqu'à 64 caractères) et d'un va-et-vient constant et rapide, il existe plusieurs options pratiques.

Et EventChartCustom n'est pas le meilleur, car il entre dans la file d'attente des événements OnChartEvent().

Mais lorsqu'il s'agit de transférer rapidement plus de 1000 symboles dans les deux sens, EventChartCustom et la file d'attente des événements entraînent des retards (par exemple, lors du rechargement des tableaux et de l'utilisation des animations).

Le passage rapide par les ressources est discutable.

Dis-moi, ça ne veut pas charger un disque ?

 

À en juger par le silence, ce sera probablement le cas.

Voilà, vérifiez-le).

 
Реter Konow:

Transfert rapide via les ressources - en question.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading

Nouvelle version de MetaTrader 5 build 1930 : fenêtres graphiques flottantes et bibliothèques .Net dans MQL5

fxsaber, 2018.12.09 00:18

Cet exemple s'exécute maintenant 15x plus vite

1000000
Time[TestResource()] = 286646


En gros, un cycle complet de ticks d'écriture/lecture dans la ressource fonctionne à 4 millions de ticks par seconde.


J'ai un mot à dire, ça ne va pas peser sur le disque dur ?

Le disque n'est pas utilisé dans l'opération de ressource. Tout est en mémoire.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading

Bugs, bugs, questions

fxsaber, 2018.12.11 09:19

Vérifié, 60Mb est écrit en toute sécurité (MT4/5) dans les ressources. Donc s'il y a une limite, elle est plus élevée.

 
fxsaber:


Le lecteur n'est pas utilisé lorsque vous travaillez avec des ressources. Tout est en mémoire.

Merci. Cette option demeure donc.

 
fxsaber:


Le lecteur n'est pas utilisé lorsque vous travaillez avec des ressources. Tout est en mémoire.

Et le testeur ? Les ressources créées dans le testeur seront-elles visibles en dehors du testeur ? Et sont-ils créés dans le testeur ?

ZS. Un camarade ici, a dit que les ressources - il est inconnu si elles fonctionnent dans le testeur.))
 
Реter Konow:

Et le testeur ? Les ressources créées dans le testeur seront-elles visibles en dehors du testeur ?

Et sont-ils créés dans le testeur ?

Je n'ai pas vérifié si les ressources fonctionnent dans le testeur de stratégie. S'ils fonctionnent, ils seront visibles dans MT4 parce que le testeur est à l'intérieur du terminal, mais pas dans MT5 parce que le testeur n'est pas connecté au terminal. Vous pouvez y échanger des fichiers uniquement par le biais de fichiers communs.


Lorsque j'ai examiné les informations ci-dessus, je n'ai eu qu'une seule solution, je me suis posé une question et j'y ai répondu en vérifiant le code. Je le recommande.

 
fxsaber:

Je n'ai pas vérifié si les ressources fonctionnent dans le testeur de stratégie. S'ils fonctionnent, ils seront visibles dans MT4, car le testeur se trouve à l'intérieur du terminal, mais pas dans MT5, car le testeur n'est connecté au terminal d'aucune façon. Seul l'échange y est possible par le biais de Common-files.

Je vois. Je dois le vérifier. Je vais le vérifier aujourd'hui.

1...848586878889909192939495969798...184
Nouveau commentaire