Actually, I screwed up the timing info. I wasn't including the time for the QueryWrapperFilter#bits(IndexReader) call. Sadly, it actually takes longer than the original query that had both terms included. Bummer. I had really convinced myself till the thought came to me at lunch :).
-M On Wed, Apr 16, 2008 at 6:43 PM, Karl Wettin <[EMAIL PROTECTED]> wrote: > Michael Stoppelman skrev: > > Hi all, > > I've been doing some performance testing and found that using > > QueryWrapperFilter for a location field > > restriction I have to do allows my search results to approach 5-10ms. > > This > > was surprising. > > Before the performance was between 50ms-100ms. > > > > The queries from before the optimization look like the following: > > +(+(text:cats) +(loc:1 loc:2 loc:3 ...)) > > > > The QueryWrapperFilter does do a search itself. Why would performance be > > so > > drastically different when the > > QueryWrapperFilter needs to do a search? Does lucene just not have the > > statistics to optimize this query so it > > can decide which terms to filter by first? > > > > Do you wonder why a QueryWrapperFilter is faster than a Query? Then the > answer is that the filter uses a bitset to know if a document matches a > document or not. For each document that match text:cats it checks the flag > in the bitset for that document number instead of seeking in the index to > find out if also match loc:1, loc:2 or loc:3. > > > karl > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
