lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-6365) Optimized iteration of finite strings
Date Wed, 20 May 2015 16:48:00 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14552643#comment-14552643
] 

Michael McCandless commented on LUCENE-6365:
--------------------------------------------

bq. The Iterator interface is not possible with the current implementation, because the lookahead
of hasNext() would destroy the current value provided by the previous next(). Anyway, I removed
that comment.

OK it's fine if we don't implement Java's Iterator; the spirit of that TODO can still be removed
:)

bq. I provided now both interfaces (single use and multiple use) with the newest patch, so
for the default case you can use the more intuitive one (single use). I hope you like it.

Sorry, I really don't want to pollute such a low level API with reuse ... can you remove the
init reuse method?

bq. I kept the limit inside the iterator, but provided the new class LimitedFiniteStringsIterator
for it. Because it was too complicated to transfer the limit into the yet complex iteration
in AnalyzingSuggester etc.

OK that seems like a good compromise...

> 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,
FiniteStringsIterator5.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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message