lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn van Groningen (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (SOLR-2564) Integrating grouping module into Solr 4.0
Date Wed, 08 Jun 2011 11:12:58 GMT

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

Martijn van Groningen edited comment on SOLR-2564 at 6/8/11 11:12 AM:
----------------------------------------------------------------------

{quote}
I've been checking out the performance, and it generally seems fine. But of course we normally
short circuit based on comparators and often don't get beyond that... so to exercise &
isolate the rest of the code, I tried a worst-case scenario where the short circuit wouldn't
work (sort=docid desc) and solr trunk with this patch is ~16% slower than without it. Any
ideas what the problem might be?
{quote}

What might be the problem is that the trunk is using (Grouping.java 589):
{code}
SearchGroup smallest = orderedGroups.pollLast();
{code}

Whilst the AbstractFirstPassGroupingCollector (line 217) is using:
{code}
final CollectedSearchGroup<GROUP_VALUE_TYPE> bottomGroup = orderedGroups.last();
orderedGroups.remove(bottomGroup);
{code}
The above also happen around line 271.

I haven't checked this out, but I think it is the most likely explanation between those two
implementations. Retrieving the bottom group will be done in almost all cases when the short
circuit doesn't work 

      was (Author: martijn.v.groningen):
    {quote}
I've been checking out the performance, and it generally seems fine. But of course we normally
short circuit based on comparators and often don't get beyond that... so to exercise &
isolate the rest of the code, I tried a worst-case scenario where the short circuit wouldn't
work (sort=docid desc) and solr trunk with this patch is ~16% slower than without it. Any
ideas what the problem might be?
{quote}

What might be the problem is that the trunk is using (Grouping.java 589):
{code}
SearchGroup smallest = orderedGroups.pollLast();
{code}

Whilst the AbstractFirstPassGroupingCollector (line 217) is using:
{code}
final CollectedSearchGroup<GROUP_VALUE_TYPE> bottomGroup = orderedGroups.last();
orderedGroups.remove(bottomGroup);
{code}
The above also happen around line 271.

I haven't checked this out, but I think it is the most likely explanation between those two
implementations. Retrieving the bottom will be done in almost all cases when the short circuit
doesn't work 
  
> Integrating grouping module into Solr 4.0
> -----------------------------------------
>
>                 Key: SOLR-2564
>                 URL: https://issues.apache.org/jira/browse/SOLR-2564
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Martijn van Groningen
>            Assignee: Martijn van Groningen
>             Fix For: 4.0
>
>         Attachments: LUCENE-2564.patch, SOLR-2564.patch, SOLR-2564.patch, SOLR-2564.patch,
SOLR-2564.patch, SOLR-2564.patch
>
>
> Since work on grouping module is going well. I think it is time to wire this up in Solr.
> Besides the current grouping features Solr provides, Solr will then also support second
pass caching and total count based on groups.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


Mime
View raw message