Erreurs, bugs, questions - page 2780
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
Ne pleure pas, ça fait longtemps que je n'ai pas répondu:
Malheureusement, le résultat s'est avéré être non seulement nul, mais négatif...
Eh bien, pourquoi négatif...
Je ne l'ai pas eu la première fois, je ne l'ai pas eu la deuxième fois, mais je l'ai eu la troisième fois.
Je n'y peux rien si je suis si épaisse. Ce n'est pas de ta faute.
Alors, ne sois pas offensé, Sergei.
Vous avez une mauvaise compréhension des termes asynchrone et synchrone.
Lorsqu'on dit qu'une fonction est asynchrone, cela signifie qu'elle sera exécutée non pas dans le fil d'exécution actuel, mais dans un autre fil.
L'appel d'une fonction asynchrone comme ChartSetInteger à partir du thread principal est rapide car l'exécution réelle a lieu dans un thread différent.
En revanche, l'appel d'une fonction synchrone ChartGetInteger nécessitera la synchronisation des threads, ce qui peut prendre du temps supplémentaire.
Les retards sont particulièrement perceptibles lorsque le fil parallèle met constamment à jour les données de la structure du graphique (par exemple, lorsque l'utilisateur déplace la fenêtre du graphique ou fait défiler l'historique).
Le plus souvent, pour des raisons de simplicité et de fiabilité, un seul objet de synchronisation est utilisé pour sa structure de données graphique.
Vous pouvez essayer d'améliorer la vitesse d'exécution en utilisant la "segmentation des données", mais d'un autre côté, vous pouvez maintenant vous heurter à des blocages, à des données insuffisamment mises à jour ou à des ralentissements à d'autres endroits plus critiques.
D'une manière générale, il est préférable de ne pas toucher à quelque chose qui fonctionne déjà de manière stable.
Non. Les méthodes Get sont synchrones, mais elles peuvent être regroupées et exécutées simultanément, de sorte que l'appel à la méthode 1 Get ou 100 est presque identique.
Les méthodes Set sont asynchrones, mais elles peuvent aussi être groupées pour plus d'efficacité.
Ainsi, il est toujours préférable de regrouper les "Appels groupés" et les "Appels groupés" plutôt que les "Appels groupés/appels groupés/appels groupés/appels groupés".
Les appels asynchrones sont plus efficaces si le thread appelant n'est pas bloqué pendant l'exécution de la fonction, mais vous perdrez ces avantages si vous mélangez Get et Set.
J'espère que cela vous aidera, malgré la traduction.
Si je comprends bien, Get est synchrone, car il renvoie le résultat demandé. Mais si vous avez des Set asynchrones dans la file d'attente, vous devez vous synchroniser avec eux.
S'il n'y a que des Get dans la file d'attente, il n'y a pas de retard.
Merci à tous. Je commence lentement à m'y habituer.
Maintenant, la véritable image de ces retards devient claire.
Si je comprends bien (corrigez-moi, s'il vous plaît, si je me trompe) :
Lorsque la méthode Get est appelée à partir du thread principal, une demande est adressée au chart thread lui-même, qui s'exécute parallèlement au thread principal. Mais le thread principal est contrôlé directement par les méthodes Set et le thread principal devrait déjà connaître l'état actuel du thread de la carte, mais il ne connaît pas l'état actuel du thread de la carte et ne sait pas si les dernières commandes ont été exécutées. C'est pourquoi cette demande se produit, pour s'assurer que toutes les commandes précédentes ont été exécutées. Comme la méthode Get est synchrone, elle attend qu'une réponse soit reçue du fil d'exécution graphique parallèle. C'est la raison des retards.
Si je n'ai pas fait d'erreur, une question se pose :
Pourquoi le thread principal ne peut-il pas signaler au thread que sa commande est exécutée, de sorte que le thread principal puisse marquer la commande comme exécutée et mettre à jour sa table de diagramme interne ? Ensuite, le thread principal renverrait les données de la table sans faire de demandes au thread principal. En outre, vous pouvez passer un drapeau indiquant qu'il y a des commandes qui ne sont pas encore exécutées au fil parallèle ou que toutes les commandes ont été exécutées pour comprendre l'état actuel du graphique. Il n'y aura pas de retard avec ce projet.
J'ai implémenté un mécanisme à peu près similaire dans la classe iCanvas.
Voici un indicateur, démontrant ce mécanisme, où il y a une fonction ChartXYToTimePrice incroyablement lente pour associer les coordonnées des pixels avec le temps et le prix du graphique et créer son analogue, la fonction XYToTimePrice, qui met à jour ses variables statiques internes à l'événement CHARTEVENT_CHART_CHANGE et calcule les paramètres demandés sur la base des données de ce graphique statique des paramètres du graphique.
Merci à tous. Je commence doucement à m'y faire.
...C'est vrai. Et, comme Renat l'a dit, le système de cache doit être implémenté du côté mql. Peut-être pourrait-on l'implémenter du côté de la plate-forme, mais cela compromettrait la réalisation de l'architecture multithread la plus productive possible.
Je vois.
Tant mieux pour ceux qui comprennent comment mettre en œuvre ce système de cache, et tant pis pour ceux qui ne le comprennent pas.
Je vais essayer d'utiliser une analogie, si ça ne marche pas comme ça, alors tant pis.
C'est très exagéré et pas vrai, mais quand même.
Il y a vous, le client, qui déterminez et apportez les peintures à l'artiste, et il y a l'artiste, qui utilise les peintures que vous apportez et peint avec elles sur la toile.
Après avoir apporté les peintures, vous êtes libre de vaquer à vos occupations : travail, maison, école, ......
Vous pouvez également visiter le peintre à tout moment et contrôler le résultat.
Toutefois, si vous venez pour une inspection et que l'artiste est en train de peindre, vous devrez attendre qu'il ait terminé son travail.
La meilleure façon d'interagir est d'apporter au peintre toutes les peintures dont il a besoin, de lui ordonner de peindre et de vaquer ensuite à ses occupations.
À la fin, si nécessaire, vous pouvez rendre visite au peintre pour des inspections autant de fois que nécessaire pour accéder aux toiles.
La façon la plus sous-optimale d'interagir est d'apporter au peintre une peinture à la fois et d'exiger le résultat tout de suite, en attendant que le peintre termine son travail à chaque fois.
Quel est le problème de la 2485 par rapport à la construction 2009 :
. Artist s'est rapproché de vous, le temps de déplacement pour l'inspection a commencé à passer moins, ce qui est un plus.
Cependant, l'artiste a commencé à consacrer beaucoup de temps à des travaux "à temps partiel" sur le côté.
Il avait l'habitude de prendre des "emplois à temps partiel" avec la même fréquence, mais maintenant il faut attendre trop longtemps que l'artiste ait terminé son travail.
Je vois.
Tant mieux pour ceux qui comprennent comment mettre en œuvre ce système de cache, et tant pis pour ceux qui ne le comprennent pas.
La meilleure façon d'interagir est d'apporter au peintre toutes les peintures dont vous avez besoin, de lui ordonner de peindre, puis de vaquer à vos occupations.
À la fin, si nécessaire, vous pouvez rendre visite au peintre pour une inspection autant de fois que vous le souhaitez - vous aurez libre accès à la toile.
À mon avis, la meilleure solution consiste à convenir avec l'artiste que, dès qu'il aura terminé une peinture, il indiquera sur son site une œuvre achevée particulière, qui pourra être consultée, et à convenir également qu'il indiquera son statut actuel - s'il travaille à temps partiel ou gratuitement.
Vous saurez alors quelle photo est prête et laquelle ne l'est pas sans avoir à rendre visite à l'artiste. Si ce dernier est occupé ou libre en ce moment, vous pourrez lui envoyer le prochain travail. Et il n'y aura pas besoin de voyager en vain avec une inspection. Cela permettra de gagner du temps et de ménager les nerfs du client et de l'artiste.
1) Dans mon esprit, la meilleure façon est de convenir avec l'artiste,
2) dès qu'il termine une peinture régulière,
3) puis il a immédiatement indiqué un travail spécifique fait sur leur site, qui est disponible pour la visualisation par le client,
4) ainsi que d'accepter de préciser sur le site de son statut actuel - il est occupé moonlighting ou libre.
5) Le client saura alors .... Si l'artiste est actuellement occupé ou libre, vous pouvez lui envoyer le prochain travail.
6) Et il n'y aura pas besoin de voyager en vain avec l'inspection. Cela permettra de gagner du temps et de ménager les nerfs du client et de l'artiste.
1) L'artiste ne connaît pas vos projets et vous ne connaissez pas non plus l'avenir...
2) Il n'y a pas de tableaux, il n'y a qu'une seule toile sur laquelle se font toutes les manipulations et tous les "bricolages".
3) Introduire dans une analogie des processus sans rapport avec le matériau source, c'est ne pas comprendre ce qu'est une analogie et à quoi elle sert.
4) Un peintre ne connaît pas l'avenir et si vous devez venir pour une inspection, son statut peut changer cent fois pendant le trajet.
5) Vous pouvez apporter de la peinture à tout moment, le délai est toujours le même, quel que soit le statut de l'artiste ou son emploi.
6) Encore une fois, ne pas comprendre l'essence de ce qu'est une analogie et à quoi elle sert...
l'équipe de peinture de 3ème classe m'a demandé de dire au peintre abstractionnistehttps://www.mql5.com/ru/forum/343547
qui n'a pas peint correctement les supports dans la ME, qu'il faut faire quelque chose à ce sujet, ou il y a une suggestion de prendre les pinceaux et de taper sur le chevalet