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

Alan Woodward commented on LUCENE-6228:
---------------------------------------

Here's the benchmark results:
{code:java}
TaskQPS baseline      StdDevQPS my_modified_version      StdDev                
Pct diff
              AndHighMed      917.55      (4.4%)      873.99      (7.0%)   
-4.7% ( -15% -    6%)
              HighPhrase     1045.07      (8.3%)     1009.68      (8.2%)   
-3.4% ( -18% -   14%)
             AndHighHigh      937.55      (5.9%)      909.34      (6.1%)   
-3.0% ( -14% -    9%)
               LowPhrase     1286.87      (5.6%)     1250.09      (5.8%)   
-2.9% ( -13% -    8%)
                 Prefix3      350.81     (11.8%)      341.21     (11.9%)   
-2.7% ( -23% -   23%)
                  Fuzzy1      413.16      (4.2%)      402.44      (7.1%)   
-2.6% ( -13% -    9%)
        HighSloppyPhrase     1385.38      (6.3%)     1356.77      (8.8%)   
-2.1% ( -16% -   13%)
                Wildcard      984.38      (5.2%)      967.81      (3.4%)   
-1.7% (  -9% -    7%)
               OrHighMed      884.32      (5.2%)      870.05      (7.3%)   
-1.6% ( -13% -   11%)
       HighTermMonthSort     3629.00      (5.4%)     3579.19      (5.3%)   
-1.4% ( -11% -    9%)
               MedPhrase     1021.25      (5.7%)     1007.93      (5.1%)   
-1.3% ( -11% -   10%)
                 MedTerm     5695.18     (11.1%)     5631.21      (9.8%)   
-1.1% ( -19% -   22%)
                  IntNRQ     1679.89      (3.5%)     1661.20      (2.9%)   
-1.1% (  -7% -    5%)
                 LowTerm     7382.84      (9.0%)     7327.15     (10.5%)   
-0.8% ( -18% -   20%)
         LowSloppyPhrase     1641.31      (7.8%)     1630.47      (6.2%)   
-0.7% ( -13% -   14%)
              AndHighLow     3016.41     (11.5%)     3001.77     (12.5%)   
-0.5% ( -21% -   26%)
                PKLookup      216.00      (2.0%)      215.21      (2.7%)   
-0.4% (  -4% -    4%)
                 Respell      391.05      (6.2%)      390.08      (9.3%)   
-0.2% ( -14% -   16%)
             LowSpanNear     1536.24      (7.1%)     1539.79      (5.6%)    
0.2% ( -11% -   13%)
            HighSpanNear      722.00      (4.4%)      723.73      (5.5%)    
0.2% (  -9% -   10%)
   HighTermDayOfYearSort     1217.56      (7.7%)     1224.19     (10.5%)    
0.5% ( -16% -   20%)
              OrHighHigh      529.66      (8.8%)      532.79      (5.6%)    
0.6% ( -12% -   16%)
                HighTerm     4502.17      (8.6%)     4535.50      (7.3%)    
0.7% ( -13% -   18%)
             MedSpanNear     1194.29      (7.2%)     1206.77      (6.5%)    
1.0% ( -11% -   15%)
               OrHighLow     1261.48      (9.2%)     1285.74      (6.7%)    
1.9% ( -12% -   19%)
                  Fuzzy2       83.02     (12.8%)       84.71     (15.4%)    
2.0% ( -23% -   34%)
         MedSloppyPhrase     1006.45     (11.2%)     1049.12     (11.2%)    
4.2% ( -16% -   29%)
{code}

> Do not expose full-fledged scorers in LeafCollector.setScorer
> -------------------------------------------------------------
>
>                 Key: LUCENE-6228
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6228
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>            Priority: Major
>             Fix For: 5.2, 6.0
>
>         Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, 
> LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch
>
>
> Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
> several methods should never be called in the context of a Collector (like 
> nextDoc or advance).
> I think it's even more trappy for methods that might seem to work in some 
> particular cases but will not work in the general case, like getChildren 
> which will not work if you have a specialized BulkScorer or iterating over 
> positions which will not work if you are in a MultiCollector and another leaf 
> collector consumes positions too.
> So I think we should restrict what can be seen from a collector to avoid such 
> traps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to