[ 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