[
https://issues.apache.org/jira/browse/LUCENE-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543443#comment-14543443
]
Michael McCandless commented on LUCENE-6365:
--------------------------------------------
I would really prefer not make API compromises (reuse, init method) for such
optimizations, nor for the "limit" case (this is really the caller's
responsibility...).
bq. Especially annoying is to change the implementation of
CompletionTokenStream, because it has no for loop.
It's fine to just add a member to the class tracking how many strings it has
pulled so far from the iterator...
Also, you can remove that {{//TODO: make this return a Iterator<IntsRef>
instead?}} since you are doing exactly that, here...
> Optimized iteration of finite strings
> -------------------------------------
>
> Key: LUCENE-6365
> URL: https://issues.apache.org/jira/browse/LUCENE-6365
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
> Affects Versions: 5.0
> Reporter: Markus Heiden
> Priority: Minor
> Labels: patch, performance
> Attachments: FiniteStringsIterator.patch,
> FiniteStringsIterator2.patch, FiniteStringsIterator3.patch
>
>
> Replaced Operations.getFiniteStrings() by an optimized FiniteStringIterator.
> Benefits:
> Avoid huge hash set of finite strings.
> Avoid massive object/array creation during processing.
> "Downside":
> Iteration order changed, so when iterating with a limit, the result may
> differ slightly. Old: emit current node, if accept / recurse. New: recurse /
> emit current node, if accept.
> The old method Operations.getFiniteStrings() still exists, because it eases
> the tests. It is now implemented by use of the new FiniteStringIterator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
