[
https://issues.apache.org/jira/browse/LUCENE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217754#comment-15217754
]
Michael McCandless commented on LUCENE-7122:
--------------------------------------------
bq. This is a bit theoretical but lets say the block length congruency
optimization didn't occur to you. Would you have still steer'ed clear of
ByteBlockPool?
Your question is not theoretical at all: it's simply a recap of exactly what
happened on this issue: see my first patch ;)
bq. That it's internally complex is implementation detail that calling code
doesn't need to care about.
The problem is, not only is this class's implementation hairy, so its its
numerous APIs, because it has so many diverse consumers.
So, yeah, something like {{ConcurrentHashMap}} has wildly complex
implementation but a simple-ish API, but I don't put {{BytesRefArray}} and
{{ByteBlockPool}} in the same category: their APIs are messy and often changing
in very expert/trappy ways.
> 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, 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]
