[
https://issues.apache.org/jira/browse/LUCENE-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528747#comment-13528747
]
Shai Erera commented on LUCENE-4615:
------------------------------------
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.
I prefer that we keep these somewhere, and would like to propose the following:
* Don't make the allocators so visible on the API. I.e. today
StandardFacetsAccumulator takes them in the constructor. Perhaps we can move it
to a protected method?
** Then, only extensions would be exposed to it, and whoever extends SFA, or
writes his own Accumulator, IMO should be allowed to reuse arrays.
* By default, don't cache arrays. Today by default we reuse one array, and I
think that for the common case, this is not needed.
So I do like to keep the option for extensions to reuse arrays, just because
we've seen that it's needed in some cases. But I am +1 for 'hiding' that option
somewhere, so that only experts that need it, will find it :).
> 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: [email protected]
For additional commands, e-mail: [email protected]