Tiki en temps réel - page 16
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
Chers collègues, gardez à l'esprit que Print produit de manière asynchrone avec une file d'attente de sortie limitée. Si vous en avez un grand nombre, vous pouvez sauter les empreintes.
Si le tampon déborde, c'est possible, mais seuls les développeurs vous le diront. S'ils disposent de flush() après chaque impression et d'un tampon de taille suffisante, c'est peu probable.
Si le tampon déborde, c'est possible, mais seuls les développeurs vous le diront. S'ils ont flush() après chaque impression et que le tampon est suffisamment grand, c'est peu probable.
Les développeurs ont déjà dit - vous n'avez pas écouté attentivement :))
La chasse d'eau n'a rien à voir du tout avec ça. Il est utilisé dans les opérations sur les fichiers.
Les développeurs l'ont déjà dit - vous n'avez pas écouté attentivement :))
Flash n'a rien à voir avec cela - du tout. Il est utilisé pour les opérations sur les fichiers.
Je ne pense pas qu'il y ait eu de développeurs dans ce fil de discussion. Peut-être qu'ailleurs ils ont dit qu'ils pourraient sauter des impressions, mais bon sang :-) Je ne surveille pas tout ce qu'ils écrivent sur ce forum.
Oui, et l'exemple que nous analysons dans lequel l'impression n'est pas sautée, mais présente seulement une différence de 4 secondes. Et clairement le tick est unset qui est arrivé dans OnTick et dans OnBook, et le unset donne l'impression que dans OnBook il est arrivé plus tard de 4 secondes.
p.s.
Flush() est de bas niveau et de haut niveau et peut être activé immédiatement après toute sortie sur disque - si une réinitialisation est nécessaire. Et cela ne doit pas nécessairement être pour les opérations d'écriture de bas niveau.
Je voulais dire que s'il y a quelque chose à purger, il sera purgé des tampons vers le disque. Après la purge, il sera purgé vers le disque exactement quand il n'est pas coûteux de le faire.D'ailleurs, je pense que les développeurs crachent sur la perte des impressions au profit des performances.
Au fait, je pense que les développeurs crachent sur la perte des impressions au profit des performances.
La perte d'empreintes, indique que le développeur n'a pas mis en œuvre la file d'attente.
La question de savoir si cela est bon ou mauvais est discutable.
La perte d'empreintes, indique que le développeur n'a pas mis en œuvre la file d'attente.
La question de savoir si cela est bon ou mauvais est discutable.
Je ne sais pas, ils sauront.
Il serait agréable de désactiver l'enregistrement dans le testeur au profit de la vitesse, par exemple.
La perte des empreintes, suggère que le développeur n'a pas mis en œuvre la file d'attente.
La question de savoir si cela est bon ou mauvais est discutable.
Ceci n'est valable que pour la sortie sur l'écran. Toutes ces impressions sont enregistrées dans le fichier sans aucune perte.
J'ai compris, j'ai confondu l'empreinte avec l'arrivée de la tique.
Vraiment, l'impression est très en retard.Il s'avère alors que la fonction d'impression est à blâmer.
Et peut-être que pour les tests, il est préférable de sortir le résultat dans un fichier.
Voici un exemple simple pour vérifier cela : imprimer une boucle décente,
et vous pouvez immédiatement voir la vitesse de rendu des impressions et le temps des impressions sera normal.
C'est uniquement lorsqu'il est affiché à l'écran. Toutes ces impressions sont enregistrées dans le fichier sans aucune perte.
Ouais ? Eh bien, c'est très bien alors.
Je veux dire, quand vous jouez dans le testeur, parfois vous n'avez pas du tout besoin des impressions dans le fichier ou sur l'écran, mais vous avez besoin de la vitesse.