Re: [sdx-users] performances maxsort?

[Martin Sevigny]

Salut,

> > Parce que si c'est le problème que j'ai vu, alors ils
> > devraient être triés...
>
> Non, je viens de regarder à nouveau, ça "marche", c'est
> à dire que les n résultats les plus pertinents sont bien
> triés selon l'ordre demandé, et les suivants sont
> présentés dans l'ordre décroissant de pertinence.

OK. Merci pour le test. J'ai regardé de plus près et ça peut se comprendre.

En fait, je l'écris ici pour s'en rappeler, mais le code est optimisé
pour maxSort, mais à moitié...

Classe SortSpecification, lignes 232 et suivantes:

ResultDocument[] docs = res.getDocuments();
if(this.getMaxSort() == SortSpecification.SORT_UNLIMITED)
    Arrays.sort(docs, this);
else if( this.getMaxSort() > 0 )
   Arrays.sort(docs, 0, ((this.getMaxSort()< docs.length) ?
this.getMaxSort() : docs.length) - 1, this);
res.setSortedResults(docs);
return res;

Le tri s'effectue réellement sur les maxSort premiers résultats, mais
dans tous les cas on appelle res.getDocuments() qui va lire tous les
documents retournés par les résultats, pas seulement les maxSort premiers...

... et je ne crois pas que ce soit très efficace. En fait, le tri serait
négligeable par rapport au temps pour lire l'index Lucene, ce qui ne
m'étonne pas du tout, même si je n'ai jamais testé.

Le problème, c'est que ce n'est pas trivial de récupérer uniquement les
maxSort premiers documents de l'index Lucene, car on n'a jamais prévu
d'avoir une liste de résultats qui serait composée de "ResultDocument"
et de "Hits", on a toujours soit une liste de ResultDocument, soit une
liste de Hits.

Bref, si c'est bien là le problème, je n'ai pas de solution rapide.

> En revanche, s'agissant des temps de réponse, ils sont
> en fait plutôt pires avec maxsort que sans...?

Humm... Réellement? Difficile à expliquer...

Martin Sévigny