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

Erick Erickson commented on SOLR-4656:
--------------------------------------

David:

bq:  Shouldn't the field value lengths be accumulated,
I see where you're going, and I have I admit I didn't originate this code so 
all things are possible.
It's a little different sense than maxAnayzedChars in that the unit of 
measurement is the number of MV entries rather than the number of characters 
analyzed, but I could argue either way.

bq:  shouldn't this field value loop exit early once ...
I have no objection.

Although it sees kind of late to take away this parameter, should we deprecate 
it insteas?





> Add hl.maxMultiValuedToExamine to limit the number of multiValued entries 
> examined while highlighting
> -----------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-4656
>                 URL: https://issues.apache.org/jira/browse/SOLR-4656
>             Project: Solr
>          Issue Type: Improvement
>          Components: highlighter
>    Affects Versions: 4.3, Trunk
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Minor
>             Fix For: 4.3, Trunk
>
>         Attachments: SOLR-4656-4x.patch, SOLR-4656-4x.patch, 
> SOLR-4656-trunk.patch, SOLR-4656.patch
>
>
> I'm looking at an admittedly pathological case of many, many entries in a 
> multiValued field, and trying to implement a way to limit the number 
> examined, analogous to maxAnalyzedChars, see the patch.
> Along the way, I noticed that we do what looks like unnecessary copying of 
> the fields to be examined. We call Document.getFields, which copies all of 
> the fields and values to the returned array. Then we copy all of those to 
> another array, converting them to Strings. Then we actually examine them. a> 
> this doesn't seem very efficient and b> reduces the benefit from limiting the 
> number of mv values examined.
> So the attached does two things:
> 1> attempts to fix this
> 2> implements hl.maxMultiValuedToExamine
> I'd _really_ love it if someone who knows the highlighting code takes a peek 
> at the fix to see if I've messed things up, the changes are actually pretty 
> minimal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to