[
https://issues.apache.org/jira/browse/SOLR-12616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571042#comment-16571042
]
Varun Thacker edited comment on SOLR-12616 at 8/7/18 2:33 AM:
--------------------------------------------------------------
I can't seem to track down the difference b/w SortDoc and SingleValueSortDoc
and why SingleValueSortDoc is so much faster.
I tried another round of experiments where I assumed SortDoc will only have one
sort field and modified the following functions to mimic SingleValueSortDoc .
The only difference at this point from SingleValueSortDoc is that sortValues is
still an array of length one VS a variable. The speed difference still exists
{code:java}
public void setValues(SortDoc sortDoc) {
this.docId = sortDoc.docId;
this.ord = sortDoc.ord;
this.docBase = sortDoc.docBase;
sortValues[0].setCurrentValue((sortDoc.sortValues[0]));
}
public boolean lessThan(Object o) {
if(docId == -1) {
return true;
}
int comp = sortValues[0].compareTo(sd.sortValues[0]);
if(comp == -1) {
return true;
} else if (comp == 1) {
return false;
} else {
return docId+docBase > sd.docId+sd.docBase;
}
}
{code}
To bring back the old performance the one approach we could take is still keep
the specialized classes for upto 4 sort fields by doing this in the export
writer
{code:java}
if (sortValues.length == 1) {
return new SingleValueSortDoc(sortValues[0]);
} else if (sortValues.length == 2) {
return new DoubleValueSortDoc(sortValues[0]);
} ... for 3 and 4 sort fields ..
else {
return new SortDoc(sortValues);
}
{code}
was (Author: varunthacker):
I can't seem to track down the difference b/w SortDoc and SingleValueSortDoc
and why SingleValueSortDoc is so much faster.
I tried another round of experiments where I assumed SortDoc will only have one
sort field and modified the following functions to mimic SingleValueSortDoc .
The only 1 difference being sortValues is still an array of length one VS a
single variable. The speed difference still exists
{code:java}
public void setValues(SortDoc sortDoc) {
this.docId = sortDoc.docId;
this.ord = sortDoc.ord;
this.docBase = sortDoc.docBase;
sortValues[0].setCurrentValue((sortDoc.sortValues[0]));
}
public boolean lessThan(Object o) {
if(docId == -1) {
return true;
}
int comp = sortValues[0].compareTo(sd.sortValues[0]);
if(comp == -1) {
return true;
} else if (comp == 1) {
return false;
} else {
return docId+docBase > sd.docId+sd.docBase;
}
}
{code}
To bring back the old performance the one approach we could take is still keep
the specialized classes for upto 4 sort fields by doing this in the export
writer
{code:java}
if (sortValues.length == 1) {
return new SingleValueSortDoc(sortValues[0]);
} else if (sortValues.length == 2) {
return new DoubleValueSortDoc(sortValues[0]);
} ... for 3 and 4 sort fields ..
else {
return new SortDoc(sortValues);
}
{code}
> Track down performance slowdowns with ExportWriter
> --------------------------------------------------
>
> Key: SOLR-12616
> URL: https://issues.apache.org/jira/browse/SOLR-12616
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
> Reporter: Varun Thacker
> Priority: Major
> Attachments: SOLR-12616.patch
>
>
> Just to be clear for users glancing through this Jira : The performance
> slowdown is currently on an unreleased version of Solr so no versions are
> affected by this.
> While doing some benchmarking for SOLR-12572 , I compared the export writers
> performance against Solr 7.4 and there seems to be some slowdowns that have
> been introduced. Most likely this is because of SOLR-11598
> In an 1 shard 1 replica collection with 25M docs. We issue the following
> query
> {code:java}
> /export?q=*:*&sort=id desc&fl=id{code}
> Solr 7.4 took 8:10 , 8:20 and 8:22 in the 3 runs that I did
> Master took 10:46
> Amrit's done some more benchmarking so he can fill in with some more numbers
> here.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
