[sdx-developers] RE : Gestion de la mémoire

[Martin Sevigny]

Bonjour,

> L'instanciation et la configuration sont logiquement 
> gourmands en ressources. On ne pourra rien y changer sauf à 
> revoir le modèle en lançant par exemple un thread de 
> configuration qui, au fur et à mesure de son avancée, rendra 
> disponible tel ou tel objet. NetBeans a adopté un processus 
> de ce genre : à lire les mailing-listes, ça n'est pas sans 
> poser de problèmes... (quoique le modèle d'instantiation de 
> SDX soit assez déterministe, contrairement à celui de 
> NetBeans). De plus, je me demande si ça vaut le coup, un 
> serveur de production pouvant accepter une initialisation une 
> fois de temps en temps (donc... P5).

Quelle instanciation est si gourmande en ressources?

> Le chargement de documents est extrêmement gourmand. A 
> réserver aux périodes creuses... On pourrait améliorer en 
> dissociant le processus de chargement, lent par nature, et 
> celui d'indexation, gourmand en ressources... et indexer par 
> petits lots les documents chargés mais non encore indexés.

Oui. Et je vous signale également qu'avec une judicieuse utilisation des
entrepôts, il est tout à fait concevable d'indexer les documents sur un
autre serveur que ce lui où ils seront cherchés. Pour l'instant, il faut
le bricoler à la main.

> En ce qui concerne l'indexation Lucene, les temps varient de 
> façon exponentielle (v. échanges récents). J'ai déjà parlé 
> d'autres types de solutions (et j'en reparlerai ;-). En 
> accès, par contre, c'est très rapide... je pense même qu'on 
> ne peut quasiment pas faire mieux sauf à attaquer directement 
> le matériel en assembleur.

En indexation, il faut jouer avec IndexParameters.setBatchMax pour
obtenir de bonne performances. Pas encore dans la taglib mais dans l'API
Java oui. Maintenant, l'indexation se fait en mémoire, dans un nouvel
index. Après chaque "batch", l'index est "mergé" avec le véritable
index. Ce merge est gourmande, mais maintenant on peut faire en sorte
qu'il n'arrive pas très fréquemment. Ca dépend de la mémoire
disponible...

> Les XSL le sont aussi, mais là, j'ignore comment elles sont 
> mappées en mémoire...

Ca dépend du processeur. JAXP prévoit un objet Templates qui correspond
à une XSLT compilée. Chaque processeur XSLT le construit comme il veut.

> Selon moi, les objets sachant exploiter du SAX ont un 
> footprint mémoire au moins aussi important qu'un DOM qui, 
> lui, peut se contenter d'objets très légers.

Humm, bizarre ce commentaire. Un flux SAX peut ne rien avoir en mémoire
s'il n'en a pas besoin. Un objet DOM est toujours aussi complet, peu
importe ce qu'on en fait...

>  Dans ce combat 
> sans merci, il y a selon moi match nul :-))) 

Absolument pas. Ce sont deux API différentes. Voir ci-dessous.

> J'ai donc bien 
> peur que nos XSL soient particulièrement gourmandes car, pour 
> pouvoir attraper convenablement tous les évènements SAX d'une 
> XSL complexe (celles de sdxworld par exemple :-), il en faut 
> des lignes de bytecode !

En fait, voilà le point important. Le flux générateur -> transformateurs
-> sérialiseur se fait en événément SAX. Toutefois, tous les processeurs
XSLT actuellement disponibles doivent construire un arbre complet (selon
le modèle Xpath, pas le DOM...) des documents traités afin de pouvoir
effectuer la transformation. C'est le goulot d'étranglement qui fait en
sorte qu'un processeur générateur -> XSLT -> sérialiseur tout simple est
(presque) aussi gourmand en SAX qu'en DOM. Toutefois, s'il y a plusieurs
étapes, on peut être gagnant.

Il y a un autre gain : tous les processeurs XSLT sauf celui de Microsoft
(je crois) sont plus efficaces s'ils reçoivent du SAX que s'ils
reçoivent du DOM. C'est en particulier le cas de Saxon.

> - on pourrait peut-être améliorer le code. Tout objet SDX ou 
> presque se voit fournir un logger. J'ignore que qu'Avalon 
> prend comme ressources pour ça... Il y a là un point à étudier.

Ce n'est pas toujours le même? Donc un seul pointeur de plus?

> - la construction d'un objet Results prend du temps. Sous SDX 
> 1 (je n'ai pas encore testé suffisamment SDX 2), le tri était 
> à la limite du supportable, mais je crois que Lucene a fait 
> des progrès dans ce domaine... 

C'est SDX qui fait le tri. Il y a un bean associé à Lucene qui le fait
maintenant, mais je crois que l'approche est la même... Sans être
international.

A bientôt,

Martin Sévigny