Julien Nioche wrote:
However in most cases the
application would be faster because :
- tree access to the Term (this is only the case for the Terms in the .tii)
- no need to create up to 127 temporary Term objects (with creation of
Strings and so on....)
- limit garbage collecting
The .tii is already read into memory when the index is opened. So the
only savings would be the creation of (on average) 64 temporary Term
objects per query. Do you have any evidence that this is a substantial
part of the computation? I'd be surprised if it was. To find out, you
could write a program which compares the time it takes to call docFreq()
on a set of terms (allocating the 64 temporary Terms) to what it takes
to perform queries (doing the rest of the work). I'll bet that the
first is substantially faster: most of the work of executing a query is
processing the .frq and .prx files. These are bigger than the RAM on
your machine, and so cannot be cached. Thus you'll always be doing some
disk i/o, which will likely dominate real performance.


To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 10 | next ›
Discussion Overview
groupjava-dev @
postedDec 4, '03 at 2:39p
activeDec 5, '03 at 11:34p



site design / logo © 2021 Grokbase