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

[Pierrick Brihaye]

Re,

> Quelle instanciation est si gourmande en ressources?

Entendons-nous bien : une installation est *toujours* gourmande en
ressources : elle doit se synchroniser avec des threads de plus bas niveau,
demander de la mémoire à l'OS... SDX n'est ni pire ni meilleur qu'un autre
programme dans ce domaine.

Ensuite, on est en palier... jusqu'à ce qu'arrivent les premières
connections. Mais, normalement, Cocoon a préparé les pools.

>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.

Vu.

>En indexation, il faut jouer avec IndexParameters.setBatchMax pour
>obtenir de bonne performances.

Oui, mais le profiling risque d'être assez compliqué. Est-ce que le jeu en
vaut la chandelle pour une opération qui devrait être assez épisodique ?

> Pas encore dans la taglib mais dans l'API
>Java oui.

Vu.

>> 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...

Tu rectifies plus bas ce qui, en fait, était ma pensée :

>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.

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

>Absolument pas.

Tu as raison. Mais le match nul est là selon moi : bâtir un DOM est
l'exploiter revient, en termes de ressources, à peu près au même que de
traiter en SAX en X-Path. Ce n'est qu'une intuition cependant...

>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.

On est d'accord. Je pense effectivement qu'il faut soigneusement penser ses
pipelines pour gagner en performance. Un exemple d'optimisation dans ce
domaine serait bienvenu.

>> - 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?

A priori si, mais j'ignore ce qu'on fait une fois qu'on a déréférencé le
pointeur :-)

>> - 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.

Certes, mais il m'a semblé comprendre que Lucene avait amélioré les API de
retour des champs, qui servent évidemment de base au tri... A voir.

En fait, le gros problème pour moi, c'est l'API de retour des hits : ça
renvoie un tableau, ce qui implique ce tableau soit intégralement bâti en
mémoire en amont. A vue de nez, je pense que créer une Factory pour des
applications qui seraient des Handler aurait été plus performant. Mais
peut-être y a-t-il dans Lucene une implémentation de bas-niveau qui
imposerait la construction d'un tableau ?!

A+

p.b.