Visualiser les détails du résultat
| Identifiant | Projet | Catégorie | Visibilité | Date de soumission | Dernière mise à jour |
|---|---|---|---|---|---|
| 0001286 | SIC | EdiSic Résultats | public | 2016-11-02 12:45 | 2016-11-03 15:31 |
| Rapporteur | dorch | Assigné à | dorch | ||
| Priorité | normale | Impact | mineur | Reproductibilité | toujours |
| Statut | fermé | Résolution | corrigé | ||
| Version du produit | 5.35j | ||||
| Version ciblée | 5.37a | Résolu dans la version | 5.37a | ||
| Résumé | 0001286: Affichage très lent des données par objet (section, noeud...) | ||||
| Description | Sur un exemple avec une simulation en transitoire sur un réseau conséquent et beaucoup de pas de temps, l'affichage des données sur une section, un ouvrage, un noeud ou une prise est très lent (Plusieurs dizaines de secondes sur la Garonne avec une simulation comportant plus de 1000 pas de temps) alors même que les résultats sont chargés en mémoire. | ||||
| Balises | Aucune balise n'est associée. | ||||
| Temps projeté (jours) | |||||
|
|
C'est l'initialisation du champ CMB_Noeud qui est en cause : Fin d'initialisation de CMB_Noeud 1 21 s 015 ms 99.911138% Avec le calcul des écart au noeud introduit en février 2016 (Ticket Mantis non trouvé). Plusieurs pistes à explorer : - Ne provoquer cette initialisation que sur les objets traitant des noeuds (noeud, prise, ouvrage de prise) - Regarder le code pour voir s'il n'y a pas une optimisation possible de l'algo - Stocker les informations produites pour ne pas les récalculer à chaque affichage - Calculer les données en tâches de fond à la fin du chargement des résultats |
|
|
Contrairement à ce que je pensais, il n'y a pas de définition de temps de début et de fin d'analyse des résultats qui servirait à cadrer la calcul des valeurs min et max des données. Il n'est donc pas nécessaire de gérer ce cas d'utilisation dans le cadre d'un stockage des écarts aux noeuds. |
|
|
Une première mise à jour de la routine permet de n'effectuer le calcul qu'une seule fois au premier affichage et une optimisation de la routine a permis de diviser par presque 4 son temps d'exécution : Procédure locale Pl_InitElementEC 1 6 s 519 ms 99.999114 Par contre, je pense qu'il faudrait migrer le calcul de cet écart dans le calcul traditionnel des variables supplémentaires de résultat accessibles depuis le bouton "Paramètres avancés" des tableaux de résultats. De cet façon, on aurait accès à toute la panoplie de traitement des données (tri, graphiques..) et l'écart max en cours de simulation serait accessible via le mécanisme existant de calcul des mini et maxi des variables. |
|
|
Suppression du calcul de l'écart dans le combo noeud. Tout est repris par 0001287. |
| Date de modification | Nom d’utilisateur | Champ | Changement |
|---|---|---|---|
| 2016-11-02 12:45 | dorch | Nouveau bogue | |
| 2016-11-02 12:45 | dorch | Statut | nouveau => affecté |
| 2016-11-02 12:45 | dorch | Assigné à | => dorch |
| 2016-11-02 12:52 | dorch | Note ajoutée: 0001371 | |
| 2016-11-02 12:54 | dorch | Note ajoutée: 0001372 | |
| 2016-11-02 17:45 | dorch | Note ajoutée: 0001373 | |
| 2016-11-02 18:55 | dorch | Statut | affecté => fermé |
| 2016-11-02 18:55 | dorch | Résolution | ouvert => corrigé |
| 2016-11-02 18:55 | dorch | Résolu dans la version | => 5.37a |
| 2016-11-03 15:31 | dorch | Note ajoutée: 0001380 |
