Actualités


Les premiers tests en utilisation réelle ont permis d'identifier un sérieux problème de performances.

Un ensemble de 110 Notes XT3 (pesant 971 Ko) a été importé. Aucun lag ni à l'import ni à l'utilisation dans le nouveau Bloc-notes. Par contre, aux ouvertures suivantes, XT4 prend 10 secondes pour lire le fichier de données qui pèse désormais 1.64 Mo "grâce" aux balises XML.

Après debug, le code XT n'est pas en cause, ni les instructions Delphi utilisées. Le problème vient de l'instruction SelectSingleNode du Parser XML "MSXML.dll" inclut dans Windows, utilisé pour accéder à chaque élément de l'arbre DOM. Il semble que cette fonction parcoure à chaque fois l'ensemble de l'arbre comme décrit par d'autres utilisateurs. Il faudra donc passer par l'écriture d'une routine spécifique, sans doute inspirée de ce code.

En attendant de trouver une correction valable, XT4 va être modifié pour concaténer en une seule chaîne les multiples lignes des textes, en espérant que la réduction du nombre de balises réduise le temps de chargement. Pour le moment le fichier compte 26800 lignes et contient donc autant de balises.

Résultat


Le stockage des multiples lignes de texte en une seule ligne est assez satisfaisant :

• C'est extrêmement simple à mettre en place, Delphi s'occupant de transformer la longue chaîne en multiples lignes (et vice versa) grâce à la propriété Text des StringList.
• Le fichier résultant pèse exactement 1 Mo contre 1.64 avant.
• Il ne contient plus que 1039 balises XML et se charge en 2 secondes, ce qui est mieux (5 fois plus rapide) même si pas encore acceptable.

Sinon, il est possible que ce mode de stockage des textes soit conservé même quand le problème de SelectSingleNode aura été réglé, car si visuellement les lignes semblent concaténées et donc peu lisibles via un browser ... ...elles seront bien plus faciles à modifier via un éditeur de texte, car débarrassées des balises <Line> qui entouraient chaque ligne :

Bug XT359


Il est possible de colorier les cellules du calendrier depuis XT359, sorti début 2006.

Le format de fichier ayant changé à cette occasion, les données ont alors été converties.
Il semble qu'il y avait dans cette conversion un bug qui a dupliqué certaines lignes : Cela ne posait pas de problème dans XT3, qui ne s'occupait que de la première ligne trouvée pour une date : Par contre, l'import XT4 a été adapté, désormais il ignore ces lignes corrompues au lieu de provoquer un crash en tentant de les interpréter.

Bien vu pour le Test a lieu des N Lines.
Mais ce pbm de perf est lamentable. Pas possible de browser ton arbre DOM différemment? Genre en parcourant toi même les ChildNodes?

DMo a écrit :Bien vu pour le Test a lieu des N Lines.
Mais ce pbm de perf est lamentable. Pas possible de browser ton arbre DOM différemment? Genre en parcourant toi même les ChildNodes?

Oui c'est ce qu'il va falloir faire.


Moins évident mais quand même notable sur des gros fichiers, les routines Delphi de manipulation des TreeView et ListView sont également reconnues pour être très peu optimisées. Par exemple, XT4 prend plus de temps pour faire le Clear d'un Treeview que pour le charger ensuite ! Certains disent qu'à la place du Clear, ils effacent récursivement tous les Nodes et que c'est quasi-instantané. Et sinon il faudrait aussi débrancher les OnChange de ces composants avant toute modification lourde, car ils sont exécutés malgré les BeginUpdate et EndUpdate ajoutés autour du code pour désactiver les Repaint graphiques.


Sinon, avec FBu on vient de discuter de la problématique de volume des Notes, et on s'oriente vers la possibilité de stocker certaines Notes en externe (fichiers TXT). L'idée de mélanger les notes internes et externes était déjà apparue, mais il s'agissait de fichiers TXT purs, l'idée de FBu est d'en permettre le cryptage, ce qui en ferait presque des fichiers XNotes d'XT3.


Toutes ces optimisations seront très intéressantes, mais avant il faut faire le dernier outil : Copier-coller.

ok

A la réflexion, il y a deux problèmes avec l'utilisation de SelectSingleNode.


- Le premier est bien le bug Microsoft qui fait qu'au lieu d'arrêter la recherche dès qu'il a atteint la branche voulue, SelectSingleNode se constitue une liste de toutes les branches dont le chemin correspond au XPath fourni, et retourne ensuite la première branche de cette liste.
- Cela veut dire que : (1:) 100% des éléments de l'XML sont comparés avec l'XPath fourni au lieu de 50% en moyenne, et que (2:) la résolution de ce bug via l'écriture en Delphi d'une routine qui s'arrêterait dès qu'une branche est trouvée, ne diviserait les temps que par deux.


- Le second problème est une erreur de design XT4 : la fonction SelectSingleNode est supposée être utilisée pour retrouver un (seul) élément particulier perdu au fond d'un arbre, par exemple celui se trouvant au bout de l'XPath suivant : "/Data/Children[0]/Data/Children[0]". La recherche se fait donc depuis la racine de l'arbre DOM.
- Hors XT4 n'a pas besoin de faire ce genre de recherche précise puisque sa seule utilisation de l'arbre XML est de boucler massivement sur la totalité de son contenu et d'en créer des objets XT4. Il faut donc qu'XT4 utilise d'autres routines, et se "déplace" dans l'arbre XML en ne traitant que les enfants immédiats, soit en les listant avec du SelectNodes ou ChildNodes avant de boucler dessus, soit en les accédant directement par des FirstChild, et NextSibling.


-> En conclusion, c'est un problème XT.

BV, bonne conclusion
ET c'est plus "fun" de se faire son parcours soi-même. Parcours en "Profondeur d'abord" ou en "largeur d'abord"???

DMo a écrit :BV, bonne conclusion
ET c'est plus "fun" de se faire son parcours soi-même. Parcours en "Profondeur d'abord" ou en "largeur d'abord"???

Je ne connais pas trop les termes, et je ne savais pas qu'il y avait deux sortes de récursif.
Après avoir traité un élément, je traite sa descendance. Ce n'est qu'après ça que je traite ses frères.
Donc ça dépends de l'angle de vue non ?

oui, c'est "profondeur d'abord": sous arbre traité avant frêres.