[jira] [Updated] (LUCENE-7258) Tune DocIdSetBuilder allocation rate

["David Smiley (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-7258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Smiley updated LUCENE-7258:
---------------------------------
    Summary: Tune DocIdSetBuilder allocation rate  (was: Tune Spatial RPT Intersects allocation rate)

Wonderful graphs [~jwartes]!

Any thoughts on this one [~jpountz]?  I think a 2x growth rate makes more sense to me, and FWIW aligns with what java.util.ArrayList does.  org.apache.lucene.util.ArrayUtil.oversize says:
{code}
    // asymptotic exponential growth by 1/8th, favors
    // spending a bit more CPU to not tie up too much wasted
    // RAM:
{code}

I have had blind faith to simply use ArrayUtil.grow/oversize whenever I need to grow an array but it's shaken now.  I guess it depends.  If the array to be built is temporary, then don't use it -- grow by 2x; but if it may be long-lived then use it.

> Tune DocIdSetBuilder allocation rate
> ------------------------------------
>
>                 Key: LUCENE-7258
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7258
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/spatial
>            Reporter: Jeff Wartes
>
> LUCENE-7211 converted IntersectsPrefixTreeQuery to use DocIdSetBuilder, but didn't actually reduce garbage generation for my Solr index.
> Since something like 40% of my garbage (by space) is now attributed to DocIdSetBuilder.growBuffer, I charted a few different allocation strategies to see if I could tune things more. 
> See here: http://i.imgur.com/7sXLAYv.jpg 
> The jump-then-flatline at the right would be where DocIdSetBuilder gives up and allocates a FixedBitSet for a 100M-doc index. (The 1M-doc index curve/cutoff looked similar)
> Perhaps unsurprisingly, the 1/8th growth factor in ArrayUtil.oversize is terrible from an allocation standpoint if you're doing a lot of expansions, and is especially terrible when used to build a short-lived data structure like this one.
> By the time it goes with the FBS, it's allocated around twice as much memory for the buffer as it would have needed for just the FBS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org