[
https://issues.apache.org/jira/browse/LUCENE-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986637#action_12986637
]
Jason Rutherglen commented on LUCENE-1574:
------------------------------------------
bq. I think likely alloc of big BitVector, System.arraycopy, destroying it, may
be a fairly low cost compared to lucene resolving the deleted term, indexing
the doc, flushing the tiny segment, etc.
Right, and if we pool the byte[]s we'd take the cost of instantiating and
GC'ing out of the picture in the high NRT throughput case. It's counter
intuitive and will require testing.
> 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
>
> Attachments: LUCENE-1574.patch
>
> 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
