[jira] [Updated] (SOLR-12882) Eliminate excessive lambda allocation in FacetFieldProcessorByHashDV.collectValFirstPhase
[
https://issues.apache.org/jira/browse/SOLR-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-12882:
Priority: Minor (was: Major)
> 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
>Assignee: David Smiley
>Priority: Minor
> Attachments:
> start-2018-10-31_snapshot___Users_tim_Snapshots__-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png,
> start_-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png
>
> 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 = (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
[jira] [Updated] (SOLR-12882) Eliminate excessive lambda allocation in FacetFieldProcessorByHashDV.collectValFirstPhase
[
https://issues.apache.org/jira/browse/SOLR-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Underwood updated SOLR-12882:
-
Attachment:
start-2018-10-31_snapshot___Users_tim_Snapshots__-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png
> 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
> Attachments:
> start-2018-10-31_snapshot___Users_tim_Snapshots__-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png,
> start_-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png
>
> 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 = (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
[jira] [Updated] (SOLR-12882) Eliminate excessive lambda allocation in FacetFieldProcessorByHashDV.collectValFirstPhase
[
https://issues.apache.org/jira/browse/SOLR-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Underwood updated SOLR-12882:
-
Attachment: start_-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png
> 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
> Attachments: start_-_YourKit_Java_Profiler_2017_02-b75_-_64-bit.png
>
> 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 = (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
