Sam 25/02/2012 - Actualités


12:05

Le split des données enfants en deux listes Children et Folders selon leur flag Container a finalement été abandonné, après plusieurs jours d'hésitations, d'analyse et un commencement d'implémentation. Gérer deux racines de descendance sur chaque objet demandait trop de rework, la quasi-totalité des services étant impactés.

Retour donc à la case départ : chaque objet a une seule liste Children pour tous les enfants. Afin de gérer correctement les opérations de recherche, insertion et déplacement, des nouveaux services permettant de manipuler les enfants selon leur index absolu ou selon leur "ContIndex" (leur index selon le flag Container) ont été créés.
Après une suprenante quantité de corrections (les opérations de déplacement ne géraient absolument pas la distinction Dossier/Donnée ! ), la finalisation de l'outil Contacts va pouvoir reprendre.

15:05

La sélection multiple a finalement été activée "juste pour voir" sur la liste des Contacts. Le drag-and-drop de multiples Contacts et Informations vers un autre dossier fonctionne correctement. (Seuls les Contacts sont en fait déplacés, les Informations restant toujours rattachées à leur Contact). Il restera à gérer la sélection multiple dans les autres opérations (Suppression, Couper, Copier, Coller, Monter et Descendre). Cela ne devrait pas poser de difficulté particulière et sera fait plus tard.

16:30


Afin d'alléger un peu le fichier des données, un système de valeurs par défaut a été implémenté :

• Lors de l'écriture, certaines données ne sont plus stockées si elles correspondent à la valeur par défaut.
• Lors de la lecture, le service qui lit la valeur d'un élement XML est désormais appelé avec une valeur par défaut, qu'il renvoit si l'élement est introuvable.

19:00

Après avoir corrigé les derniers bugs apparents de l'outil Contacts, il était temps de jouer un peu avec les performances.

Un Contact avec 5 Informations a donc été dupliqué 10 fois dans un dossier. Ce dossier a été dupliqué 10 fois dans un dossier parent, lequel a été dupliqué 10 fois dans un autre dossier parent, lui aussi dupliqué 10 fois. Cela donne donc un total de 1.000 dossiers contenant 10.000 Contacts et 50.000 Informations.

Résultats :

• Le fichier XML a 164.000 lignes mais assez étonnamment ne pèse que 7,5 Mo, ce qui est un bon résultat.
• Par contre il faut près de 8 secondes pour lire le fichier et en créer les 10.000 objets.
• Une fois en mémoire, il n'y a pas de latence sensible dans la manipulation des Contacts, après la petite seconde nécessaire à l'ouverture de l'outil.
• L'occupation mémoire est de 21 Mo, contre 14 Mo pour mon XT3 de référence, ce qui laisse penser qu'il n'y a pas de fuite mémoire.

(Tests réalisés avec un processeur cadencé à 3 Ghz, les autres caractéristiques de la machine n'influant pas.)

Impressionnant ton test de volumétrie !!! Et c'est plutôt bon signe. Surtout que je n'ai pas (encore) autant de contacts...
Sinon, pour les valeurs par défaut, c'est très bien et très pratique quant tes versions vont évoluer: ainsi si tu rajoute des infos "obligatoires", tu sauras toujours relire un vieux fichier XML car ca rajoutera les valeurs par défaut si pas trouvé. En revanche, lors de l'écriture du fichier, je stockerais tous les champs, pas que les non-défaut. Ainsi si les valeurs par défaut changent d'une version à l'autre, une utilisateur aura ses valeurs stockées et ne subira ainsi pas de changement de comportement.... Accessoirement, c'est moins de code à faire (ou à maintenir maintenait qu'il est fait), et le gain en taille du XML est minime... Donc vite le

J'espère bien que personne n'aura jamais 10.000 objets, ça voudrait dire que le soft aurait dû être payant.
A part le côté fun, c'était aussi pour valider les choix structurels de ces derniers mois, en particulier les données en objets hiérarchisés et le stockage en XML.

Les données non stockées sont pour le moment :

• Les booléens valorisés à False. Cette valeur par défaut est plus technique que fonctionnelle, donc pas de risque qu'une version future en ait vraiment besoin.
• Les chaines vides, certains champs n'étant pas utilisés par tous les objets. J'évite l'écriture d'un élément vide <Tag/>.

Exemple lors de la lecture :