[
https://issues.apache.org/jira/browse/LUCENE-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527621#comment-13527621
]
Shai Erera commented on LUCENE-4600:
------------------------------------
bq. Why try to recycle the int[]'s? Why not let GC handle it...?
It was Gilad who mentioned "believes" and "religions" .. that code is written
since Java 1.4. Not sure that at the time Java was very good at allocating and
disposing arrays ... Also, it's not like this is unique to facets. IIRC,
IndexWriter also holds onto some char[] or byte[] arrays? At least, few days
ago someone asked me how come IW never releases some 100 MB of char[] - since
he set RAM buffer size to 128 MB, it made sense to me ...
Perhaps leave it for now, and separately (new issue? :)) we can test if
allocating a new array is costly? If it turns out that this is actually
important, we can have a cleanup thread to reclaim the unused ones?
> Explore facets aggregation during documents collection
> ------------------------------------------------------
>
> Key: LUCENE-4600
> URL: https://issues.apache.org/jira/browse/LUCENE-4600
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Attachments: LUCENE-4600-cli.patch, LUCENE-4600.patch,
> LUCENE-4600.patch
>
>
> Today the facet module simply gathers all hits (as a bitset, optionally with
> a float[] to hold scores as well, if you will aggregate them) during
> collection, and then at the end when you call getFacetsResults(), it makes a
> 2nd pass over all those hits doing the actual aggregation.
> We should investigate just aggregating as we collect instead, so we don't
> have to tie up transient RAM (fairly small for the bit set but possibly big
> for the float[]).
--
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: [email protected]
For additional commands, e-mail: [email protected]
