[
https://issues.apache.org/jira/browse/LUCENE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-7122:
---------------------------------------
Attachment: LUCENE-7122.patch
OK how about this as a compromise?
I added a new (package private!) class, {{FixedLengthBytesRefArray}}, and a
minimal common interface (also package private) between it and the existing
public {{BytesRefArray}}, which {{OfflineSorter}} holds.
{{BytesRefArray.java}} is otherwise unchanged.
I don't think we should try factor out a common base class, for the reasons
listed above, but also because I think we may want to later improve how values
are stored in {{FixedLengthBytesRefArray}} vs the more generic
{{BytesRefPool}}, e.g. sizing each block so that a value never crosses a
boundary. But that's for later...
> BytesRefArray can be more efficient for fixed width values
> ----------------------------------------------------------
>
> Key: LUCENE-7122
> URL: https://issues.apache.org/jira/browse/LUCENE-7122
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7122.patch, LUCENE-7122.patch
>
>
> Today {{BytesRefArray}} uses one int ({{int[]}}, overallocated) per
> value to hold the length, but for dimensional points these values are
> always the same length.
> This can save another 4 bytes of heap per indexed dimensional point,
> which is a big improvement (more points can fit in heap at once) for
> 1D and 2D lat/lon points.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
