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

David Smiley resolved LUCENE-6422.
----------------------------------
    Resolution: Fixed

BTW I did a little more benchmarking.  For point data there's a nice 10% 
improvement or so.  Smaller index size too.  For non-point data I used pruning 
and a distErrPct of 0.025 (default).  The recursive prune of RPT on legacy quad 
(does more pruning then packed quad) amounted to a 25% smaller index than 
PackedQuad, and the index & search were practically the same.  I can only 
surmise PackedQuad required less memory while indexing, of course.  I _suspect_ 
that if RPT's recursive prune were to do its thing on PackedQuad, PackedQuad 
would have a better showing.  I'll leave that benchmark to another day.  My 
experience (& benchmarks) have shown that there is a high correlation between 
index size and search, and that pruning helps a ton.  Some day I may write a 
better recursive prune that doesn't require buffering all tokens.

Thanks again for contributing this Nick!

> Add PackedQuadPrefixTree
> ------------------------
>
>                 Key: LUCENE-6422
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6422
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/spatial
>    Affects Versions: 5.x
>            Reporter: Nicholas Knize
>            Assignee: David Smiley
>             Fix For: 5.2
>
>         Attachments: LUCENE-6422-TRUNK.patch, LUCENE-6422.patch, 
> LUCENE-6422.patch, LUCENE-6422.patch, LUCENE-6422.patch, LUCENE-6422.patch, 
> LUCENE-6422_with_SPT_factory_and_benchmark.patch
>
>
> This task introduces a PackedQuadPrefixTree that includes two things:
> 1.  A packed 8 byte representation for a QuadCell, including more efficient 
> implementations of the SPT API than the existing QuadPrefixTree or 
> GeoHashPrefixTree.
> 2.  An alternative implementation to RPT's "pruneLeafyBranches" that streams 
> the cells without buffering them all, which is way more memory efficient.  
> However pruning is limited to the target detail level, where it accomplishes 
> the most good.
> Future improvements over this approach may include the generation of the 
> packed cells using an AutoPrefixAutomaton



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

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

Reply via email to