[
https://issues.apache.org/jira/browse/LUCENE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213337#comment-15213337
]
David Smiley commented on LUCENE-7122:
--------------------------------------
+1 Patch looks nice Mike. I think a separate class is good; it's not that long.
bq. manage its own byte blocks (not rely on the overly complex ByteBlockPool),
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?
That it's internally complex is implementation detail that calling code doesn't
need to care about. The surface API could be clearer, yes. I could be
mistaken but I recall you or Rob complaining about that class before, and it's
not clear to me what will become of it (if anything).
> 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]
