[
https://issues.apache.org/jira/browse/LUCENE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15206454#comment-15206454
]
Michael McCandless commented on LUCENE-7122:
--------------------------------------------
bq. Hey by the way, I think it would be useful for us to consider modifying our
Javadoc publishing to prevent publishing @lucene.internal classes. I think that
would help assuage some of your concern at the root of this matter.
+1, can you open a new issue?
bq. I'm coming at this out of the usefulness of the data structure/utility for
use within Lucene (since that's where BytesRef is defined of course); not from
an efficiency standpoint although I could make such an argument.
Hmm but the only valid reason to use {{BytesRefArray}} instead of
{{BytesRef[]}} is efficiency?
bq. For that, look no further than your friend Mike who is using it as
described in this issue.
"Mike" is not using it. Names should not be attached to our source code ;)
Lucene's {{OfflineSorter}}, used heavily by the new dimensional points feature,
is using it. And the inefficiency of 4 heap bytes per value is non-trivial,
very much so for the likely common {{IntPoint}} use case, but also heavily so
for e.g. {{LatLonPoint}} as well.
> 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]
