[
https://issues.apache.org/jira/browse/LUCENE-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14613686#comment-14613686
]
Uwe Schindler commented on LUCENE-6365:
---------------------------------------
bq. I agree that reuse is no good design, but the profiler pointed me to that
spot. I already did a patch for Automaton (LUCENE-5959) for the same reasons.
The problem with profilers is: They don't run the code with all hotspot
optimizations turned on (because they add extra commands into the loop) to take
measurement points. In general Object creation is in most cases not bad, except
when they tend to live long time (e.g., across several method). Short living
objects never affect GC, because they are created on stack automatically
(escape analysis) - and those are in most cases never shown correctly by
profiler, because escape analysis is mostly broken with profilers.
Reuse is only suitable for cases where the object goes through many stages of
a query and needs to be cached between method calls and involves disk I/O,...
This is not the case here.
Patch without reuse looks fine, although I dont fully understand it (not my
area of work).
> 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: FiniteStrings_noreuse.patch, FiniteStrings_reuse.patch,
> LUCENE-6365.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
