Optimisation des Lock::care(DEFAULT) : Une fonction care_DEFAULT
a été ajoutée à Lock
pour augmenter la vitesse de cette opération qui était générale
et qui commencait par un DEFAULT.cure(DEFAULT)
qui était inutile. Vu que cette routine est appelée des millards
de fois par cas-tests, on y gagne beaucoup.
Optimisation de l'accès à la DB : Vu le constat alarmant
fait par Ludovic sur les performances désastreuses des nouvelles routines
de conctact, j'ai mis au point une classe qui permet de gérer manuellement
l'accès à la base de données Oofelie. Le problème
était localisé dans l'appel de la fonction pos()
au niveau des points. Cette fonction retourne la position courante du point
en faisant 2 get_properties()
pour demander les infos nécessaires àla DB. Autrement dit, un
beau paquet de get_properties()
en cascade (opencascade? - que celui qui m'a lu jusqu'ici, m'envoie un mail
pour me féliciter de ce jeu de mot...).
La nouvelle classe "FastPhyset"
règle le problème en court-circuitant le traditionnel mécanisme
Physet. Elle dérive directement de Physet et fournit une interface
pour intercepter certains appels get_properties()
et y répondre à la place de la DB. L'inconvénient, c'est
qu'il faut mettre à jour manuellement les raccourcis.
Pour voir l'interface, voir ./basic_cl/oo_fe/fastphyset.h
Par défaut, toutes les classes de oo_geo
sont des FastPhyset. Pratiquement
(dans Metafor), on ne l'utilise que pour le PointSet.
Ainsi, le PointSet gère
les positions de Points, ce
qui ne demande qu'un seul get_properties().
Il serait intéressant d'appliquer la méthode pour les autres
objets géométriques qui sont les "pères" (au sens Physet)
des éléments. Ca boosterait encore un peu Metafor.
Optimisation des Vectstr::update() : Vectstr::update()
est une routine très peu optimisée vu qu'elle n'était
pas fort utilisée dans les problèmes traités par Igor.
Pour l'algorithme explicite de Metafor, on en fait un beau paquet par pas
de temps si bien qu'Oofelie passait beaucoup plus de temps dans update()
que dans l'élément lui même (et ce, même pour des
cas 3D).
J'ai ré-écrit cette routine (uniquement pour des Vectstr
pointant vers la DB) en utilisant des std::map.
Résultat: la nouvelle routine, appelée Vectstr::fast_update()
tourne très vite (j'ai observe des facteurs 20 sur des petits cas 2D!)
en restant toujours générale (et c'est ça l'important).
J'ai mis au point une routine Vectstr::ligthning_update()
qui est censée aller encore plus vite mais au prix de bouffer de la
RAM (la Connexion_12 trie les
ddl par type avant de les envoyer au Vectstr).
En pratique, ça va plus vite (environ un facteur 2) mais le temps gagné
au total est très faible, si bien que j'ai privilégié
l'économie de mémoire.
Le shéma suivant montre les résultats obtenus pour la batterie Metafor
: