That would be great... we need someone to pull a patch together (for SegmentReader & Multi*Reader to implement it efficiently).
Mike On Thu, Apr 16, 2009 at 9:50 AM, Shai Erera <[email protected]> wrote: > I think it's a convenient method. Even if not performing, it's still more > convenient than forcing everyone who wants to use it to implement it by > himself. Perhaps a better implementation will exist in the future, and thus > everyone who'll use this method will be silently upgraded. Maybe such a > better implementation should be considered? > > On Thu, Apr 16, 2009 at 4:46 PM, Michael McCandless > <[email protected]> wrote: >> >> Maybe we should deprecate it? >> >> Mike >> >> On Thu, Apr 16, 2009 at 9:04 AM, Mark Miller <[email protected]> >> wrote: >> > Mark Miller wrote: >> >> >> >> Robert Muir wrote: >> >>> >> >>> while I was mucking with term enumeration i found that >> >>> TermEnum.skipTo() >> >>> has a very simple implementation and has in javadocs that 'some >> >>> implementations are considerably more efficent', yet SegmentTermEnum >> >>> definitely doesn't reimplement it in a more efficient way. >> >>> >> >>> For my purposes to skip around i simply close the term enum and get a >> >>> new >> >>> one from the indexReader at a different starting point. >> >>> >> >>> Not that I want to touch it, just mentioning i thought it was a little >> >>> non-obvious that skipTo() is so inefficient, it keeps enumerating >> >>> until >> >>> compareTo() returns what it wants... >> >>> >> >>> -- >> >>> Robert Muir >> >>> [email protected] <mailto:[email protected]> >> >> >> >> Indeed - somewhat related: >> >> https://issues.apache.org/jira/browse/LUCENE-1592 >> >> >> > I've changed >> > >> > "Some implementations are considerably more efficient than that." >> > >> > to >> > >> > "Some implementations *could* be considerably more efficient than a >> > linear >> > scan. >> > Check the implementation to be sure." >> > >> > -- >> > - Mark >> > >> > http://www.lucidimagination.com >> > >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
