Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
7.5
-
None
Description
The FacetFieldProcessorByHashDV.collectValFirstPhase method looks like this:
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))); }
);
}
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.
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)));
};
FacetFieldProcessorByArray already follows this same pattern
Attachments
Attachments
Issue Links
- is caused by
-
SOLR-9480 Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)
-
- Closed
-
- links to
