[
https://issues.apache.org/jira/browse/SOLR-11595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236584#comment-16236584
]
David Smiley commented on SOLR-11595:
-------------------------------------
Hmm; true. This could be pretty simple -- a ConcurrentHashMap of String field
to CollectionStatistics. Does that sound like something committable to you? I
can create a new issue (for Lucene) and a patch with this approach.
> optimize SolrIndexSearcher.localCollectionStatistics to use cached MultiFields
> ------------------------------------------------------------------------------
>
> Key: SOLR-11595
> URL: https://issues.apache.org/jira/browse/SOLR-11595
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
> Fix For: 7.2
>
> Attachments:
> SOLR_11595_optimize_SolrIndexSearcher_collectionStatistics.patch
>
>
> {{SolrIndexSearcher.localCollectionStatistics(field)}} simply calls Lucene's
> {{IndexSearcher.collectionStatistics(field)}} which in turn calls
> {{MultiFields.getTerms(reader, field)}}. Profiling in an app with many 150
> fields in the query shows that building the MultiTerms here is expensive.
> Fortunately it turns out that Solr already has a cached instance via
> {{SlowCompositeReaderWrapper}} (using MultiFields which has a
> ConcurrentHashMap to the MultiTerms keyed by field String.
> Perhaps this should be improved on the Lucene side... not sure. But here on
> the Solr side, the solution is straight-forward.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
