Graphique lent

Forums › ProRealTime forum Français › Support plateforme ProRealTime › Graphique lent

  • This topic has 14 replies, 3 voices, and was last updated 8 years ago by avataryj.
Viewing 15 posts - 1 through 15 (of 15 total)
  • 10/02/2016 at 3:28 PM #14057
    yj

    Bonjour tous,

    En “5 ticks” et lorsque le cours évolue rapidement, je vois souvent une petite fenêtre  “Graphique Lent” m’avertir de ce que  “Le temps de rafraichissement du graphique semble long”  , par exemple 3.478 seconde … J’ai mis l’image en attaché. (remarquez dans le nom de la fenêtre, la petite icone “danger”  style panneau triangulaire, code de la route)

    Dans cette même fenêtre il est conseillé de :

    • Retirer vos indicateurs personnels ou les simplifier .
    • Réduire le nombre d’indicateur affichés.
    • Réduire le nombre de graphiques ouverts.
    • Fermer les logiciels tiers …

    J’ai essayé sur une machine nettement plus puissante, c’est décevant, l’amélioration n’est pas en proportion de la puissance et le message toujours là…

    Ce qui m’intrigue aussi c’est que le temps de calcul annoncé est le même quelque soit l’indicateur incriminé (voir image en attaché), y compris le temps total de calcul!!!

    Enfin bref la question qui m’amène c’est comment améliorer cela ? Ce serait dommage de ne pas pouvoir utiliser un indicateur dès qu’il se complique un tant soit peu. Filtres et oscillateurs sont assez gourmands…

    Une suggestion?

    Merci, y.j.

    10/02/2016 at 3:57 PM #14060
    JC_Bywan

    Je ne saurais pas décrire comment PRT jongle avec l’espace mémoire volontairement plafonné, mais de mon côté j’ai réussi à éviter les lenteurs, malgré des codes complexes, en réduisant l’historique. On pourrait croire que le calcul live ne dépendrait que de la puissance de calcul de la machine et serait indépendant de la taille de l’historique mais apparemment non. Je soupçonne qu’à taille de mémoire donnée pour une des fenêtres PRT, plus la mémoire est prise par l’historique de la fenêtre, moins il reste de mémoire pour le calcul live de la même fenêtre (mais c’est juste un soupçon, pas une certitude). Si Nicolas sait comment ça se passe en détail côté allocation mémoire, je suis partant pour en savoir plus.

    On peut imaginer que sur une vue x ticks aussi petite que le 5 ticks, soit tu as trop d’historique dès le départ, soit ça va au départ mais très vite l’historique grandit au point de créer des lenteurs, sans que tu en aies besoin d’autant. Donc une chose à essayer, si par exemple tu as sur ton x ticks une semaine ou plus ou x unités avec x très grand, c’est de choisir seulement 2 ou 3 jours via le (x) jours. Chez moi, ça a marché avec 3 jours pour toutes les vues x ticks avec x petit. Cela dit je suis en F40 qui a beaucoup moins de ticks que l’Allemagne 30 sur une journée. Si ça se trouve il te faut tester avec seulement un jour d’historique au lancement de la fenêtre…

    10/02/2016 at 5:44 PM #14067
    Nicolas

    Je n’ai jamais eu aucun problèmes de mémoire, même en graphiques en ticks. Par conséquent, je pense que la meilleure des options est d’ouvrir un ticket support pour savoir ce qui se passe avec la plateforme. L’allocation RAM est importante, ça je le sais. Ensuite, pour diverses autres raisons liées non pas au logiciel mais au hardware et aux autres processus en mémoire, ce genre de problème on peut le rencontrer avec d’autres plateformes ou n’importe quel autre logiciel.

    Quel est ton processeur et la quantité de mémoire vive yj ?

    10/02/2016 at 9:21 PM #14079
    yj

    Merci Noobywan et Nicolas,

    • @Noobywan : En ce qui concerne l’historique, que je le veuille ou non la profondeur maximale que m’accorde PRT-cfd sur le Dax30, est de 2 journées (en fin de journée)…  J’ai beau eu réduire la voilure en ne gardant qu’une fenêtre et deux indicateurs, PRT comme unique application, ça rouspète quand le marché s’affole… La mémoire utilisée par PRT était de l’ordre  de 900Mo sur les 4G d’alloués à PRT. Cette machine compte 16G. Le processeur n’est pas le dernier I7, c’est un Xéon mais quand même… Par seconde, on peut faire des millions d’opérations et afficher des milliers de bougies…  Cela m’intrigue…   Le gestionnaire de tâche m’indiquait que les quatres cores étaient occupés à 100%… Ce qui était drôle c’était de voir que plus les ticks arrivent vite et plus lent est le rafraichissement du graphique, ce qui fait que je vois jusqu’à 12 nouvelles bougies d’un coup.  Entre deux rafraichissements j’ai compté (et lu en abcisse)  assez souvent jusqu’à 8 secondes… Le cours à le temps de remonter et descendre de manière importante puisque cela se produit quand le marché chahute…  J’ai fait une copie d’écran (ici en attaché) après avoir marqué d’une barre verticale chaque rafraichissement, on voit bien qu’à 16h09 la fréquence des ticks augmente et le rafraichissement ralenti pour redevenir régulier à chaque bougie quand ça se calme… Cet exemple est loin d’être le pire, en tout cas “scalping” interdit…
    • @Nicolas: Xeon CPU E3-1226 v3 @ 3.3GHz 16Go 64bits . Sur cette machine j’analyse quotidiennement des EEG enregistrés pendant 8 heures en continu à raison de 500 points x 8 voies à la seconde, je les transforme en fichiers son (wav) pour calculer avec SonicVizualiser, un logiciel libre, des spectrogrammes dont le calcul est monstrueux… Cela passe sans problème en quelques dizaines de secondes . Le calcul et l’affichage de nos indicateurs est ridicule en comparaison… Je ne comprends pas… Tard le soir quand les ticks arrivent au compte goutte, le gestionnaire de tâche affiche à chaque tick un pic d’activité très forte du processeur…   Dommage que tu n’aies pas souffert de ce problème, tu aurais pu me donner la solution à ces ralentissement qui surviennent sur trois machines différentes. J’en étais à me demander si je ne devrais pas faire mes calculs en dehors de PRT via une liaison DDE…(Bien que je n’y connaisse rien…)  Oui je vais faire un ticket à PRT bien que cela m’ennuie de les déranger pour cela. J’adore leur logiciel mais je commence à me demander si le développement des innombrables et merveilleux “gadgets” ne se fait pas au détriment de l’objectif premier de leur métier…

      Merci à vous deux, y.j.

    10/02/2016 at 9:22 PM #14082
    yj

    Désolé pour ces changements de police de caractère, je sais pas non plus d’où cela vient… y.j.

    10/03/2016 at 12:59 PM #14112
    Nicolas

    Le changement de caractère mise en forme vient probablement d’un copier/coller de Windows, bref pas important 🙂

    Concernant ton problème : Possèdes-tu la dernière version de Java et en 64bits? Sinon, très honnêtement, je ne pense pas du tout que tu embêteras qui que ce soit au support technique de PRT pour ce genre de problème, comme tu le stipules ton poste est capable de calcul monstrueux donc il n’est pas raisonnable que PRT rame autant .. pour si peux !

    Attention à l’utilisation des boucles FOR/NEXT par contre, qui est encore assez consommatrice de mémoire, mais c’est en train de changer.

    Par contre que tes 4 threads soient à 100% me semble vraiment très bizarre …

    10/03/2016 at 1:47 PM #14116
    JC_Bywan

    De mon côté, j’ai un i5 3570K et 8Go, sur un Windows7 64 bits, avec le launcher PRT IG qui, si j’ai bien compris, s’occupe tout seul de s’assurer d’avoir la bonne version de java. A l’époque où j’avais des problèmes de lenteur avec le même type de message que toi, je n’ai eu qu’à fermer 2 fenêtres de mon espace de travail, j’en ai gardé une dizaine, dont plus de la moitié qui font tourner des codes assez complexes, et à faire la réduction de l’historique pour les vues x ticks à x petit.

    Et en effet, comme l’évoque Nicolas, suppression des boucles For Next à chaque fois que c’est possible. Aussi, pour optimiser le code, voir le passage dans le manuel qui évoque quelle est la structure des “if… then…” qui consomme le moins. De même dans un souci d’optimisation de code complexe, si un même calcul revient souvent, le faire une fois pour toutes et stocker le résultat dans une variable et refaire appel à la variable à chaque fois plutôt que de le recalculer. Et aussi, ne pas faire de CALL, mais réécrire la portion de code nécessaire pour obtenir le même résultat que ce dont on a besoin via le call.

    Depuis, je passe les journées qui s’affolent en x ticks sans lenteur (c’est toujours amusant de voir les ticks s’affoler à peine Mario dit “bonjour” les après-midi de BCE). Les seules fois où de temps en temps j’ai un message de lenteur c’est si je modifie un des codes complexes et qu’il met longtemps à se réactualiser dans toutes les fenêtres où il est présent. Alors même les fenêtres où les recalculs sont terminés peuvent avoir une lenteur temporaire avec le message le temps que les autres fenêtres finissent l’actualisation, et ça ne dure pas au-delà de l’actualisation de la fenêtre la plus longue.

    Possible que ce soit une question de PRT complete vs PRT premium aussi? Je crois que Nicolas est en premium. Je suis en complete. Et quand on lit les caractéristiques supplémentaires de la premium, on peut se demander si la complete est limitée d’une façon ou d’une autre afin de ne pas pouvoir faire autant de choses que la premium? Mais bon, que premium vs complete compte ou pas, même en complete j’ai fini par surmonter les lenteurs avec une combinaison réduire nombre fenêtres + customiser taille de l’historique à chaque fenêtre + optimiser code.

    10/03/2016 at 2:16 PM #14125
    yj

    Merci Noobywan,

    ta réponse me redonne un peu le moral dans la mesure où “Il peut le faire”…

    Je ne situe pas exactement le xéon que j’utilise par rapport à ton I5 mais la différence ne doit pas être dans un rapport de 100…

    Théoriquement, je suis en premium.

    A un endroit de mon code, pour filtrer “close”,  j’ai un call à un filtre qui comporte une boucle mais si je garde mon close non filtré , cela ne change rien…

    De mémoire je n’ai pas de IF…

    Je ne refais jamais le même calcul…

    Et l’historique, en particulier aujourd’hui car le dax30 ne cote pas,  fait à peine plus d’une journée…

    Le support PRT me propose d’optimiser mon code, je vous tiens tous informés…

    La mémoire utilisée telle que la fenêtre de rédaction d’un “ticket”  au support PRT,  nous permet de l’observer, oscille entre 800 et 1400 Mo (sur 4G de disponibles) pour une unique fenêtre ouverte qui comporte seulement deux de mes  indicateurs…

    Je ne m’explique pas cette fluctuation de 600Mo!!!  En plus quand je lance le calcul d’un de mes indicateurs, calcul qui aujourd’hui prends de 3/4h à 1h, la quantité de mémoire utilisée n’augmente même pas!!!

    Que Java fait-il de toute cette mémoire?

    à suivre , je vous tiens au courant.

    y.j.

    10/04/2016 at 9:18 AM #14199
    yj

    Bonjour vous tous,

    Pas de nouvelles du support PRT mais néanmoins bonne nouvelle ; Depuis hier après midi c’est le jour et la nuit,  tout s’est remis en place “spontanément”.  Une coïncidence quand même, sans pour autant affirmer qu’il y a causalité, le lundi matin quand rien n’allait plus l’historique incluait la journée de vendredi puis vers 16h environ les données du vendredi ont disparues de cet historique  et le temps de calcul est maintenant si bref que je ne vois plus les barres bleues de progression, c’est instantané ! ! ! Je surveillerai lundi prochain si cela grogne encore…   Ce matin à l’ouverture alors que cela se bousculait sur le Dax30, la mise à jour était  fluide,  je n’avais plus l’avancée syncopée et lente par paquets de bougies, qui me tuait la veille…. Pour deux fenêtres totalisant 3 de mes indicateurs, la mémoire utilisée oscille autour de 200Mo alors qu’hier elle variait de 800 à 1400 pour une fenêtre, 2 indicateurs…

    Une petite angoisse résiduelle cependant  due au fait que je ne comprends toujours pas à quoi cela tient…  Cela marche  même sur le pire de mes micros qui pourtant  tourne sous XP, I3 sys32bits, 2G…

    Pourvu que cela dure…

    Et merci pour votre compassion,

    y.j.

    10/04/2016 at 9:43 AM #14201
    JC_Bywan

    Alors, pour ce cas très particulier de la lenteur du lundi matin en tout petit x ticks, qui disparait toute seule les jours suivants (ou même le lundi après-midi si on relance la plateforme) sans qu’on fasse rien en particulier, pendant longtemps ça a été la seule lenteur qui me restait, alors que les autres fenêtres de plus grand x ticks ne subissaient pas cette lenteur… Je ne sais pas à combien est la frontière, mais à 5 tu es forcément en-dessous, car j’avais cette lenteur entre 5 et 9.

    Puis un jour, “au cas où”, j’ai changé la façon de choisir l’historique de “x unités” (je prenais à peine 200 et ça ne dépassait pas une journée affichée en tout, mais c’était extrêmement lent quand même) à “x jours” (que x= 1 ou 2)… et… roulement de tambour… je n’ai plus jamais eu la lenteur sur vue x ticks, x petit, le lundi matin. Pourquoi? J’en sais rien, mais ça a marché. Vive les tests “au cas où”!

    En espérant que cette astuce fonctionne pour toi aussi lundi prochain…

     

    10/04/2016 at 10:54 AM #14205
    yj

    Noobywan, si je te suis :

    • Dans un premier temps , tu demandes     [200 unités]    [1][(x) jours]
    • Et ensuite tu changes pour                          [200 unités]    [5][(x)  ticks]

    Il y a bien sûr , une relation entre la profondeur de l’historique et le nombre d’unité d’un type donné, mais j’ai pas bien saisi l’algorithme sous-jacent de PRT. D’ailleurs j’avais fait un petit post à ce sujet… J’ai l’impression que l’on ne réduit pas la profondeur de l’historique s’il a été chargé, en réduisant le nombre d’unité… C’est contre-intuitif…

    Quant au coup du lundi PRT gère le WK d’une manière telle que sur certains codes cela peut poser problème.

    la transition   (x) jours -> (x) ticks   réalignerait quelque chose quelque part…?

    Attendons lundi prochain,   suspense… A moins qu’il faille attendre le premier lundi d’un nouveau mois…

    Merci Noobywan,  y.j.

    10/04/2016 at 11:09 AM #14207
    JC_Bywan

    Non, pour le couple [historique] et [choix de l’UT],

    c’est si j’ai [200 unités] et [5 (x)ticks] et des lenteurs,

    que je change pour [1 (x)jours] et [5 (x)ticks]

    10/04/2016 at 11:14 AM #14211
    Nicolas

    Attention toutefois également au choix du nombre de ticks de la représentation. La construction d’un graphique en 21 ticks sera différente de celle en 20 ticks, avec des chiffres ronds, je crois savoir que la construction se fait à partir de données agrégées d’autres données divisibles entières ex:5 ticks pour 20 ticks, ce qui n’est pas possible pour 21 ticks.

    10/04/2016 at 11:16 AM #14212
    yj

    Oui , t’as raison de prévenir un éventuel malentendu que ma dérive sur la profondeur des historiques peut induire.

    En tous cas merci pour l’astuce Noobywan, y.j.

    10/04/2016 at 11:24 AM #14214
    yj

    @Nicolas,

    quelles seraient les conséquences de ce mode de construction et les feux rouges à ne pas griller ?

    J’ai du mal à anticiper, y.j.

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 15 total)

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
achat / vente sur graphique
adpatation automatique du graphique
affichage des annonces de résultats sur le graphique
affichage données d’un indicateur dans échelle graphique
affichage zone sur graphique 2min
afficher sur nouveau panneau du prix/couleur d’un autre graphique prix
afficher volume et paramètre sur le graphique
calcul de l’orb de toby crabel sur graphique
décalage kijun proorder/graphique
echelle d’un graphique avec prt v12

Create your free account now and post your request to benefit from the help of the community
Register or Login