[ https://issues.apache.org/jira/browse/SOLR-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618077#comment-13618077 ]
Erick Erickson edited comment on SOLR-4656 at 3/30/13 2:02 PM: --------------------------------------------------------------- Trunk patch for comment. Haven't run through the unit tests yet. Is there a better way to get all the StorableFields in a document for a particular field than testing for the fieldName? I.e. if (! thisField.name().equals(fieldName)) seems inefficient. Patch will apply to trunk only, StorableField will need to be changed to IndexableField for 4x. was (Author: erickerickson): Trunk patch for comment. Haven't run through the unit tests yet. Is there a better way to get all the StorableFields in a document for a particular field than testing for the fieldName? I.e. if (! thisField.name().equals(fieldName)) seems inefficient. This will not apply to 4.x > 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, 5.0 > Reporter: Erick Erickson > Assignee: Erick Erickson > Priority: Minor > Attachments: 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org