Erreurs, bugs, questions - page 2961
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
Veuillez nous faire part de vos réflexions sur cette tâche (MT4) :
Je l'ai fait par le biais de variables globales. Mais cette implémentation me donne une lenteur sur GlobalVariableGet jusqu'à 100ms sur le serveur distant ! Très souvent - des dizaines de ms. Bien que je n'utilise GlobalVariableFlush nulle part, j'ai décidé de m'assurer contre d'éventuels retards de disque dur et j'ai tout converti en GlobalVariableTemp. Ça n'a pas aidé.
Ensuite, j'ai transféré tous les transferts/réceptions de données via les ressources. Ça s'est beaucoup amélioré. Il est rare que quelques millisecondes nous échappent. Dans l'ensemble, les performances se sont considérablement améliorées, le freinage brutal à plat a disparu.
Cependant, une question s'est posée : existe-t-il un autre moyen de résoudre le problème ? J'ai pensé à écrire un nombre sur une propriété du tableau. Devoir se tortiller là où je n'avais pas l'intention de le faire.
Qui utiliseGlobalVariableGet sur son VPS, pouvez-vous me dire combien de temps cela prend pour s'exécuter.
Veuillez nous faire part de vos réflexions sur cette tâche (MT4) :
Est-ce queEventChartCustom ne convient pas ?
Pourquoi ne pas simplement le mettre dans le tampon et ne pas le faire lire par le conseiller expert ? Ou l'indicateur doit-il être lancé séparément ?
EventChartCustom ne convient pas ?
Pourquoi ne pas simplement le mettre dans le tampon et le lire par l'EA ? Ou l'indicateur doit-il être exécuté séparément ?
Voici HistoryTicks - la capture de tous les ticks pour les Expert Advisors. Par conséquent, EventChartCustom n'est pas adapté, il possède sa propre file d'attente. Il en va de même pour le tampon.
Veuillez nous faire part de vos réflexions sur cette tâche (MT4) :
Je l'ai fait par le biais de variables globales. Mais cette implémentation me donne une lenteur sur GlobalVariableGet jusqu'à 100ms sur le serveur distant ! Très souvent - des dizaines de ms. Bien que je n'utilise GlobalVariableFlush nulle part, j'ai décidé de m'assurer contre d'éventuels retards de disque dur et j'ai tout converti en GlobalVariableTemp. Ça n'a pas aidé.
Ensuite, j'ai transféré tous les transferts/réceptions de données via les ressources. Ça s'est beaucoup amélioré. Il est rare que quelques millisecondes nous échappent. Dans l'ensemble, les performances se sont considérablement améliorées, le pire des freins ayant disparu sur un point plat.
Cependant, une question s'est posée : existe-t-il un autre moyen de résoudre le problème ? J'ai pensé à écrire un nombre sur une propriété du tableau. Devoir se tortiller là où je n'avais pas l'intention de le faire.
Si vous utilisezGlobalVariableGet sur votre VPS, veuillez indiquer combien de temps il faut pour l'exécuter.
Dans l'indicateur, vous créez une variable int, l'initialisez et enregistrez le nombre.
Dans l'indicateur, définissez une fonction personnalisée qui renvoie cette variable.
Définissez la fonction avec le mot-clé export.
Importez cette fonction dans le conseiller expert à partir de name_indicator.ex4
Appelez la fonction lorsque cela est nécessaire.
Je n'ai pas mesuré la vitesse.
Pas chaud, mais déjà chaud
Pas chaud, mais déjà chaud
Pour que cela reste chaud, utilisez le mappage de fichiers avec la synchronisation des événements.
Veuillez nous faire part de vos réflexions sur cette tâche (MT4) :
Je l'ai fait par le biais de variables globales. Mais cette implémentation me donne une lenteur sur GlobalVariableGet jusqu'à 100ms sur le serveur distant ! Très souvent - des dizaines de ms. Bien que je n'utilise GlobalVariableFlush nulle part, j'ai décidé de m'assurer contre d'éventuels retards de disque dur et j'ai tout converti en GlobalVariableTemp. Ça n'a pas aidé.
Ensuite, j'ai transféré tous les transferts/réceptions de données via les ressources. Ça s'est beaucoup amélioré. Il est rare que quelques millisecondes nous échappent. Dans l'ensemble, les performances se sont considérablement améliorées, le pire des freins ayant disparu sur un point plat.
Cependant, une question s'est posée : existe-t-il un autre moyen de résoudre le problème ? J'ai pensé à écrire un nombre sur une propriété du tableau. Devoir se tortiller là où je n'avais pas l'intention de le faire.
Qui utiliseGlobalVariableGet sur son VPS, veuillez vérifier son temps d'exécution.
Si l'utilisation de user32.dll n'est pas critique, voici une autre option. Je ne me souviens pas des mesures, mais j'ai écrit ci-dessous qu'il semble fonctionner rapidement. Vous avez demandé là pourquoi j'ai besoin de rapidité :)) La solution
est universelle (je peux l'utiliser entre les terminaux aussi), pas événementielle. Vous devrez travailler avec la minuterie. Cependant, le temps minimum entre les événements dansOnChartEvent ne peutpas non plus être inférieur à 1/64 de seconde.
Pour le rendre chaud, utilisez le mappage de fichiers avec la synchronisation des événements.
Conseil - en MQL pur, pensez... Il m'est venu à l'esprit