[
https://issues.apache.org/jira/browse/LUCENE-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528882#comment-13528882
]
Michael McCandless commented on LUCENE-4615:
--------------------------------------------
bq. This was required when we worked with a team that managed taxonomies with
5M+ nodes. Allocating those arrays (could be 20MB+) over and over for every
search was expensive, and I think that it's expensive with today's JVMs too.
OK. Spooky! I wonder if for such cases we should use native int[] hash map
... until the number of unique ords collected is "big enough" to warrant the
non-sparse array.
+1 for moving this abstraction to FacetArrays and making an
optional/expert/not-the-default ReusingFacetArrays.
> Remove Int/FloatArrayAllocator from facet module?
> -------------------------------------------------
>
> Key: LUCENE-4615
> URL: https://issues.apache.org/jira/browse/LUCENE-4615
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Michael McCandless
>
> Spinoff from LUCENE-4600.
> It makes me nervous to have allocation tied to our public APIs ... and the
> ability for Int/FloatArrayAllocator to hold onto N arrays indefinitely makes
> me even more nervous. I think we should just trust java/GC to do their job
> here and free the storage as soon as faceting is done.
--
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
