[
https://issues.apache.org/jira/browse/LUCENE-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985091#action_12985091
]
Michael McCandless commented on LUCENE-1574:
--------------------------------------------
I'm working on an initial patch for this...
bq. I think the only open question is how we'll shrink the pool, most likely
there'd be an expiration on the pooled objects.
I think we can simply have a "max pooled free bit vectors"... or we may want to
expire by time/staleness as well.
bq. With RT, the parallel arrays will grow, so the pool will need to be size
based, eg, when the arrays are grown, all of the previous arrays may be
forcefully evicted, or they may simply expire.
True... but, like the other per-doc arrays, the BV can be overallocated
(ArrayUtil.oversize) to accommodate further added docs.
> PooledSegmentReader, pools SegmentReader underlying byte arrays
> ---------------------------------------------------------------
>
> Key: LUCENE-1574
> URL: https://issues.apache.org/jira/browse/LUCENE-1574
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/*
> Affects Versions: 2.4.1
> Reporter: Jason Rutherglen
> Priority: Minor
> Fix For: 4.0
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> PooledSegmentReader pools the underlying byte arrays of deleted docs and
> norms for realtime search. It is designed for use with IndexReader.clone
> which can create many copies of byte arrays, which are of the same length for
> a given segment. When pooled they can be reused which could save on memory.
> Do we want to benchmark the memory usage comparison of PooledSegmentReader vs
> GC? Many times GC is enough for these smaller objects.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
