Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <30882588.1191418790825.JavaMail.jira@brutus>
Date: Wed, 3 Oct 2007 06:39:50 -0700 (PDT)
From: "Grant Ingersoll (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1017) BoostingTermQuery performance
In-Reply-To: <4909739.1191369950741.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532107 ] 

Grant Ingersoll commented on LUCENE-1017:
-----------------------------------------

You will have to look at what setFreqCurrentDoc() does.  I have a feeling, though, that there really isn't anyway around what the current version does and that the performance difference is due to it not checking all the positions on a document.  At any rate, the Span stuff needs more scrutiny performance wise, so it is worth another look.  

There should be a unit test in the code that checks multiple payloads per document, etc.  Have a look at that and try it out.  

> BoostingTermQuery performance
> -----------------------------
>
>                 Key: LUCENE-1017
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1017
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.2
>         Environment: all
>            Reporter: Peter Keegan
>         Attachments: BoostingTermQuery.java, termquery.patch
>
>
> I have been experimenting with payloads and BoostingTermQuery, which I think are excellent additions to Lucene core. Currently, BoostingTermQuery extends SpanQuery. I would suggest changing this class to extend TermQuery and refactor the current version to something like 'BoostingSpanQuery'.
> The reason is rooted in performance. In my testing, I compared query throughput using TermQuery against 2 versions of BoostingTermQuery - the current one that extends SpanQuery and one that extends TermQuery (which I've included, below). Here are the results (qps = queries per second):
> TermQuery:    200 qps
> BoostingTermQuery (extends SpanQuery): 97 qps
> BoostingTermQuery (extends TermQuery): 130 qps
> Here is a version of BoostingTermQuery that extends TermQuery. I had to modify TermQuery and TermScorer to make them public. A code review would be in order, and I would appreciate your comments on this suggestion.
> Peter

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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