[ https://issues.apache.org/jira/browse/SOLR-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16666424#comment-16666424 ]
Shawn Heisey commented on SOLR-12882: ------------------------------------- >From 2018-10-24 on the #solr-dev IRC channel: {noformat} 12:22 < tpunder> I have a few Solr Issues I'd like to get reviewed/merged (SOLR-12875, SOLR-12878, SOLR-12882, SOLR-12880). What's the best way to go about doing that? {noformat} These issues look very compelling, especially SOLR-12878. We've been fighting facet performance regression for a while now. If I had even a sliver of understanding of the code you're working on, I would help you. You might want to ping the dev list to raise visibility. > Eliminate excessive lambda allocation in > FacetFieldProcessorByHashDV.collectValFirstPhase > ----------------------------------------------------------------------------------------- > > Key: SOLR-12882 > URL: https://issues.apache.org/jira/browse/SOLR-12882 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module > Affects Versions: 7.5 > Reporter: Tim Underwood > Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The FacetFieldProcessorByHashDV.collectValFirstPhase method looks like this: > {noformat} > private void collectValFirstPhase(int segDoc, long val) throws IOException { > int slot = table.add(val); // this can trigger a rehash > // Our countAcc is virtual, so this is not needed: > // countAcc.incrementCount(slot, 1); > super.collectFirstPhase(segDoc, slot, slotNum -> > { Comparable value = calc.bitsToValue(val); return new > SlotContext(sf.getType().getFieldQuery(null, sf, calc.formatValue(value))); } > ); > } > {noformat} > > For each value that is being iterated over there is a lambda allocation that > is passed as the slotContext argument to the super.collectFirstPhase method. > The lambda can be factored out such that there is only a single instance per > FacetFieldProcessorByHashDV instance. > The only tradeoff being that the value needs to be looked up from the table > in the lambda. However looking the value up in the table is going to be less > expensive than a memory allocation and also the slotContext lambda is only > used in RelatednessAgg and not for any of the field faceting or metrics. > > {noformat} > private void collectValFirstPhase(int segDoc, long val) throws IOException { > int slot = table.add(val); // this can trigger a rehash > // Our countAcc is virtual, so this is not needed: > // countAcc.incrementCount(slot, 1); > super.collectFirstPhase(segDoc, slot, slotContext); > } > /** > * SlotContext to use during all {@link SlotAcc} collection. > * > * This avoids a memory allocation for each invocation of > collectValFirstPhase. > */ > private IntFunction<SlotContext> slotContext = (slotNum) -> { > long val = table.vals[slotNum]; > Comparable value = calc.bitsToValue(val); > return new SlotContext(sf.getType().getFieldQuery(null, sf, > calc.formatValue(value))); > }; > {noformat} > > FacetFieldProcessorByArray already follows this same pattern -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org