[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tsp-devel] RE: Amélioration importante dans JSynoptic
From: |
DUFRENNE, Yves |
Subject: |
[Tsp-devel] RE: Amélioration importante dans JSynoptic |
Date: |
Thu, 11 Mar 2004 15:59:33 +0100 |
C'est que du bonheur.
Il y a une version officielle sur le site (ou prévue dans un temps certain),
ou je fais un update -A et un commit pirate sur TSP ?
Y++
> -----Original Message-----
> From: BRODU, Nicolas
> Sent: Thursday, March 11, 2004 2:56 PM
> To: address@hidden; DUFRENNE, Yves; GONZALEZ,
> Wilfrid
> Cc: CAZENAVE, Claude
> Subject: Amélioration importante dans JSynoptic
>
>
> Bonjour,
>
> Je viens de terminer une amélioration importante dans le système de
> notifications d'évènements de JSynoptic.
> Pour résumer, ceci permet d'attendre à un niveau (Shape) que
> toute les
> notifications qui proviennent d'un évènement unique soient accomlies
> (ex: mise à jour d'une collection de données complète par le
> réseau). Je
> passe les détails d'implémentation (référence counting, remontée de
> l'enregistrement à un niveau unique pour éviter doublons, etc...). Le
> truc qui a tout débloqué était de se rendre compte que ce n'est pas
> forcément l'objet sur lequel on enregistre un listener de fin
> d'évènement qui va par la suite activer ces listeners, et
> d'autant plus
> pour éviter les doubles appels en fin d'évènement. Voir l'interface
> EndNotificationListener pour plus de détails.
>
> D'où un algorithme optimisé. Qui plus est l'ancienne
> implémentation est
> source et binaire-compatible, même si je recommande fortement
> de passer
> à la nouvelle façon de faire dans la majeure partie des cas (voir
> EndNotificationListener pour plus de détails).
>
> Exemple pour une shape qui écoute sur 2 données d'une
> collection dynamique:
>
> Avant:
> évènement extérieur => mise à jour collection
> source 1 notifie shape que son index a changé => shape notifie ses
> listeners qu'elle est changée le cas échéant
> source 1 notifie shape que sa plage de valeur a changée =>
> shape notifie
> ses listeners qu'elle est changée le cas échéant
> ...
> source 2 notifie shape que son index a changé => shape notifie ses
> listeners qu'elle est changée le cas échéant
> source 2 notifie shape que sa plage de valeur a changée =>
> shape notifie
> ses listeners qu'elle est changée le cas échéant
> ...
> timer dans AbstractShape collecte les évènements de notification des
> shapes et les fusionne à 100ms, ce qui arrive tout le temps
>
> Maintenant:
> évènement extérieur => mise à jour collection
> source 1 notifie shape que son index a changé => shape regarde si
> affectée et prend note le cas échéant
> source 1 notifie shape que sa plage de valeur a changée =>
> shape regarde
> si affectée et prend note le cas échéant
> ...
> source 2 notifie shape que son index a changé => shape regarde si
> affectée et prend note le cas échéant
> source 2 notifie shape que sa plage de valeur a changée =>
> shape regarde
> si affectée et prend note le cas échéant
> ...
> collection a fini ses mise à jour => shape prévient ses
> listener si elle
> a pris note de le faire
> timer dans AbstractShape collecte les évènements de notification des
> shapes et les fusionne à 100ms, ce qui arrive beaucoup moins souvent.
>
> L'ancien fonctionnement avait 3 problèmes:
> - La shape notifiait ses listeners à raison de N * nsources à chaque
> update réseau, où N = 2 à 4 selon les fois pour un plot
> standard. Soit
> pour un plot avec 3 données d'affichées + le temps et dans le
> meilleur
> des cas 2 *4 = 8 remontées vers JFreeChart (même si un seul dessin
> effectif tous les 100ms, les paramètres des plots étaient quand à eux
> rafraichis 8 fois!)
> - L'ordre d'arrivée des évènements était trop imprévisible
> pour pouvoir
> faire des tests propres. Par exemple, si une couleur de fond d'une
> cellule de texte de la source 1 dépend en fait de la source 2, il y
> avait 4 rafraichissements successifs, 2 pour la source 1, et
> 2 pour la
> source 2. Dans ce cas ça ne gêne pas trop, au pire il y avait
> un flicker
> si les rafraichissements étaient effectuées sur 2 intervalles
> de 100ms
> distincts. Mais nous avions vu avec Wilfrid un bug bizarre sur
> l'automate cellulaire, qui lui dépends de l'ordre d'arrivée dans
> certains cas. Ceci est encore pire pour les matrices de
> rotation en 3D...
> - De façon détournée certains listeners pouvaient être enregistrés en
> double (je passe les détails, mais c'était un effet de bord
> inévitable).
>
> Le nouveau fonctionnement permet de les résoudre
> - Il n'y a plus qu'un seul rafraichissement vers JFreeChart
> dans le cas
> ci-dessus => gain de perf non négligeable.
> - Il n'y a plus de doublons, chaque listener n'est notifié
> qu'une fois
> par évènement même s'il est enregistré en double (effet de bord
> identique, conséquences différentes).
>
> Donc, beaucoup de bugs bizzare et peu reproductibles se trouvent
> corrigés au passage, en plus d'une amélioration globale des
> performances.
>
> Happy Hacking!
> Nicolas
>
important_notice.txt
Description: Text document
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Tsp-devel] RE: Amélioration importante dans JSynoptic,
DUFRENNE, Yves <=