[
https://issues.apache.org/jira/browse/LUCENE-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490888#comment-14490888
]
Markus Heiden edited comment on LUCENE-6365 at 4/11/15 9:46 AM:
----------------------------------------------------------------
Are you talking about {code:xml}for (IntsRef finiteString; (finiteString =
iterator.next()) != null;){code}?
For me it is the standard iteration pattern for non-lookahead iterations, like
e.g. iterating over an input stream (see e.g. FileCopyUtils of Spring
framework).
Does {code:java}for (IntsRef finiteString = iterator.next(); finiteString !=
null; finiteString = iterator.next()){code} look better for you?
I like my version better, because it is shorter and the iterator.next() is not
doubled, but I will you use it, if you like it better.
A simple while loop looks even more bloated to me:
{code:java}
IntsRef finiteString = iterator.next();
while (finiteString != null) {
// do something
finiteString = iterator.next();
}
{code}
was (Author: markus_heiden):
Are you talking about {code:xml}for (IntsRef finiteString; (finiteString =
iterator.next()) != null;){code}?
For me it is the standard iteration pattern for non-lookahead iterations, like
e.g. iterating over an input stream (see e.g. FileCopyUtils of Spring
framework).
Does "for (IntsRef finiteString = iterator.next(); finiteString != null;
finiteString = iterator.next())" look better for you?
I like my version better, because it is shorter and the iterator.next() is not
doubled, but I will you use it, if you like it better.
A simple while loop looks even more bloated to me:
IntsRef finiteString = iterator.next();
while (finiteString != null) {
// do something
finiteString = iterator.next();
}
> 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
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
