Améliorer la réactivité du module Résultats

[Régis]

J'ai également ajouté ces remarques au ticket 6514.

[olivir]

Merci, Régis, ce serait une optimisation fort sympathique, je passe pas mal de temps dans Résultats, pour ma part.

[Stephane_T]

Je viens de regarder. Sur ma machine, Le module Résultats – quand il ouvre mes 37 dossiers non compressés
– génère 354 103 opérations d'ouverture/fermeture de fichiers. On pourrait économiser un peu d'énergie, Izuba, non ?

Oui, économisons l'énergie ! Il paraît même que "c'est notre avenir" (je me demande qui a imaginé une formule aussi dénuée de signification physique).

[olivir]

Pléiades Accueil charge lui aussi tous les résultats, on dirait, non ?

[Régis]

Pleiades Accueil charge lui aussi tous les résultats non compressé.

[olivir]

Hum, est-ce bien utile ?!

[Jonath]

Je plussoie la demande d'Olivir ... Perso je fait tout pour éviter Pléiades Accueil à cause de ça.

[olivir]

Je ne suis donc pas le seul

[olivir]

Il y a aussi le fait que la compression/décompression actuelle n'est pas gérée par un processus indépendant. C'est pour ça que je ne l'utilise quasi jamais, on doit attendre que ce soit fini pour pouvoir utiliser le module Résultats. Je sais pas pour vous mais chez moi c'est très long, bien plus qu'en utilisant un archiveur comme 7-zip. D'ailleurs pourquoi Pléiades ne délègue pas l'opération à un archiveur ?

[Renaud]

Bonjour,
Pour la compression/décompression effectivement, on pourrait mettre un système externe.
Sinon pour Pleiades Resultats, je viens de revérifier le code.
En fait, les seules opérations fichier, sont des scanner les dossiers de projets, scanner les dossiers de variantes, ouvrir le minuscule fichier titre.txt (qui contient les informations affichées dans la bulle d'aide) et tester l'existence de certains fichiers pour identifier le contenu (mais sans les lire).
C'est vraiment le minimum qu'on puisse faire.
Bon, cela dit, il y a peut être moyen de faire le scan des dossiers plus rapidement en utilisant une autre API. On va regarder.

De plus, chez nous, nous ne constatons aucune lenteur sur aucun PC même chargé avec des centaines de projet.

Je pense que l'émulateur pour faire tourner Pleiades sous Linux est responsable des mauvaises performances.

[olivir]

Merci pour ta réponse, Renaud. Tu as sans doute raison, l'émulation doit ralentir pour partie, ou alors c'est l'accès réseau (Mes Données Pléiades est sur un partage samba).

[Renaud]

Ah oui, le fait que "Mes données Pleiades" soit sur un réseau doit pénaliser énormément

[Renaud]

Bonjour Olivir,
J'ai un peu creusé le truc, notamment sur les "354 103" ouvertures/fermetures de fichier.
Et j'ai découvert qu'en Delphi (langage qu'on utilise), la fonction "FileExists" ouvrait et fermait un pseudo "Fichier" (qui en fait est le dossier) pour savoir si un fichier existait à l'intérieur.
Et comme on utilise de manière importante cette fonction pour savoir de quelle variante il s'agit (STD, SED, dim, RT, RE, lettre, DPE/Audit, etc...) et que je suis en train d'optimiser la gestion des fichiers résultats pour la STD....
J'ai changé la manière de faire en ouvrant une seule fois le dossier pour récupérer tous les fichiers et travailler avec.
J'espère que ça améliorera les performances quand le dossier est sur un serveur comme toi, mais ça ne va pas sortir cette année (car on est sur une branche "Performance" qui ne va pas être réintégrée tout de suite), mais probablement début 2024.

[cottet_energie]

mais ça ne va pas sortir cette année

On aime entendre ça quand on est au mois de décembre

[olivir]

Merci et bravo Renaud parce que ça a dû être un sacré boulot d'investiguer sur ce sujet !