[
https://issues.apache.org/jira/browse/LUCENE-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756905#comment-13756905
]
Areek Zillur edited comment on LUCENE-5197 at 9/3/13 6:50 PM:
--------------------------------------------------------------
Attached a patch removing redundant null checks as Adrien suggested.
First of all wanted to thank everybody for their valuable inputs.
The reasons why I choose to have an explicit method to calculate the heap size
rather than using the RAMUsageEstimator already has surfaced in the discussion
above (slow for many objects, incorrect for some type of objects).
It would be nice to have an API to call from (solr Admin for example) to
estimate the current index heap size.
I do understand the concern regarding the "out of sync with implementation
changes" concern, I mainly took into account the codecs for the size estimation
only such that higher level APIs need not to implement the method.
The suggested modified RAMUsageEstimator sounds nice, but as far as I
understand would not the logic in implementing the "excluded objects" change
just as much? while being more implicit than the proposed solution above?
was (Author: areek):
Attached a patch removing redundant null checks as Adrien suggested.
First of all wanted to thank everybody for their valuable inputs.
The reasons why I choose to have an explicit method to calculate the heap size
rather than using the RAMUsageEstimator already has surfaced in the discussion
above (slow for many objects, incorrect for some type of objects).
It would be nice to have an API to call from (solr Admin for example) to
estimate the current index heap size.
I do understand the concern regarding the "out of sync with implementation
changes" concern, I mainly took into account the
codecs for the size estimation only such that higher level APIs need not to
implement the method.
The suggested modified RAMUsageEstimator sounds nice, but as far as I
understand would not the logic in implementing the "excluded objects" change
just as much? while being more implicit than the proposed solution above?
> Add a method to SegmentReader to get the current index heap memory size
> -----------------------------------------------------------------------
>
> Key: LUCENE-5197
> URL: https://issues.apache.org/jira/browse/LUCENE-5197
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs, core/index
> Reporter: Areek Zillur
> Attachments: LUCENE-5197.patch, LUCENE-5197.patch
>
>
> It would be useful to at least estimate the index heap size being used by
> Lucene. Ideally a method exposing this information at the SegmentReader level.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
