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

[Pierrick Brihaye]

Re,

>S'il n'y a pas de tri (ordre par défaut, donc pertinence), seuls les
>hits demandés font partie du résulat.

On est d'accord.

>J'ai déjà fait un test (sans mesure scientifique) où j'avais, par
>exemple, 500 000 documents en résultat. Obtenir la page 1 (20 par page)
>ou la page 10 000 prenant exactement le même temps, les mêmes
>ressources.

C'est logique, le tableau a été construit *avant*. Pour afficher les 20
premiers résultats, il a fallu autant de temps et de ressources que si tu
avais affiché les 20 derniers.

IMHO, Lucene devrait idéalement considérer les applications comme des
consumers : si elles veulent les résultats, elles les gardent (en bâtissant
*elles-mêmes* la collection) ; si elles n'en veulent pas, elles les jettent
et ils passent dès que possible en garbage collection. Ceci permettrait par
exemple d'afficher les 20 premiers résultats pendant que les 499 980 autres
sont en train d'être construits en mémoire. Mais j'ignore si c'est
possible...

>Evidemment, je ne triais pas ces grands résultats. D'ailleurs, je me
>suis toujours dit qu'il faudrait ajouter un paramètre lorsqu'il y a tri
>: nombre maximal de documents pour réellement faire le tri. Pour se
>protéger...

Oui, c'est souhaitable (et comparable au LIMIT de SQL). Une autre idée à
creuser est la possibilité (récente) de définir soi même son score. Pour
moi, on a là un mécanisme qui, sans l'être réellement, ressemble
furieusement à un tri.

Pour prendre un exemple, mon appli est déterministe quant au tri : je serais
très intéressé de le hard-coder dans la structure des index. Ceci ne doit
bien sûr pas empêcher des tris personnalisés... protégés :-)

A voir encore une fois...

A+

p.b.