[
https://issues.apache.org/jira/browse/LUCENE-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123517#comment-13123517
]
Yonik Seeley commented on LUCENE-3500:
--------------------------------------
Not a tight loop perhaps, but I've regularly seen fast changing indexes build
up to 100 segments.
And if Solr's DocSet filter implementations need to call it again to avoid
useless wrapping, that's 200 times per query (and 400 volatile reads) that
aren't really needed.
Sure, it would be hard to measure the improvement (hence the "minor"), but it's
more about the chipping away at inefficiencies. I guess I'd turn it around and
say "why is this volatile?"... there's no reason for it to be.
> improve getLiveDocs() performance
> ---------------------------------
>
> Key: LUCENE-3500
> URL: https://issues.apache.org/jira/browse/LUCENE-3500
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Yonik Seeley
> Priority: Minor
> Attachments: LUCENE-3500.patch
>
>
> On segmentReader, liveDocs is volatile because they used to be loaded on
> demand.
> This no longer appears to be the case... liveDocs are always loaded up front.
> This also means that getLiveDocs() can never fail (even after close), and we
> can remove the ensureOpen call.
> Minor optimizations, but volatile reads still do prevent optimizations across
> that boundary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
