[
https://issues.apache.org/jira/browse/LUCENE-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551929#comment-13551929
]
Robert Muir commented on LUCENE-4678:
-------------------------------------
{quote}
I'll commit only to trunk for now ... and backport to 4.2 once 4.1 branches and
once this has baked some in trunk ...
{quote}
+1... the copyBytes is frightening though!
What do you think of the FST.BytesReader -> FSTBytesReader? I'm just thinking
it causes a lot of "api noise" (you can see it in the patch).
Unfortunately lots of users have to create this thing to pass to methods on FST
(e.g. findTargetArc).
So if we kept it as FST.BytesReader they would be largely unaffected?
> FST should use paged byte[] instead of single contiguous byte[]
> ---------------------------------------------------------------
>
> Key: LUCENE-4678
> URL: https://issues.apache.org/jira/browse/LUCENE-4678
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/FSTs
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4678.patch, LUCENE-4678.patch, LUCENE-4678.patch
>
>
> The single byte[] we use today has several limitations, eg it limits us to <
> 2.1 GB FSTs (and suggesters in the wild are getting close to this limit), and
> it causes big RAM spikes during building when a the array has to grow.
> I took basically the same approach as LUCENE-3298, but I want to break out
> this patch separately from changing all int -> long for > 2.1 GB support.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
