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

Mikhail Khludnev updated LUCENE-7863:
-------------------------------------
    Attachment: byterefshash-bench.txt
                LUCENE-7863.patch

[^LUCENE-7863.patch] with more efficient ngram mapping with BytesRefHash. 
[^byterefshash-bench.txt] benchmark results on i5 and ssd. 
h2. Summary
{code}
------------> Report sum by Prefix (index) and Round (2 about 2 out of 18)
Operation   round work dir  src                          flush  cdc             
     runCnt   recsPerRun    rec/s    elapsedSec     avgUsedMem  avgTotalMem     
    directory size, Mb
index           0 edge      EnwikiEdgeContentSource      000.00 Lucene70Codec   
     1           5000001    619.77    8,067.48   1,397,385,984  1,512,570,880   
       23,783.00
index           1 deriv     EnwikiEmptyEdgeContentSource 50.00  
DeriveBodyRevCodec   1           5000001    571.40    8,750.42   2,095,467,008  
6,383,730,688           7,687.00

 ------------> Report sum by Prefix (search) and Round (2 about 2 out of 18)
Operation   round work dir  src                          flush cdc              
    runCnt   recsPerRun   rec/s  elapsedSec    avgUsedMem    avgTotalMem 
directory size, Mb
search_50       0 edge      EnwikiEdgeContentSource     000.00 Lucene70Codec    
    1           50        17.63        2.84 1,291,492,352  1,510,998,016        
  23,783.00
search_50       1 deriv     EnwikiEmptyEdgeContentSource 50.00 
DeriveBodyRevCodec   1           50         5.97        8.38 2,205,875,712  
6,383,730,688           7,687.00
{code}

* indexing deriving terms is 8% slower than edge-ngramms
* heap consumption for indexing is 4 times greater (1.5 G vs 6.4)
* index size more than 3 times smaller. I expect bigger gain on regular indices.
* search throughput is 3 lower with derivative terms. But it's only few cold 
searches. There is a reason why searching wildcards on deriving terms is slower 
- it's random reads; however at some point absence of repeating postings should 
pays back and let it search faster eg when index isn't fully mapped.    


> Don't repeat postings (and perhaps positions) on ReverseWF, EdgeNGram, etc  
> ----------------------------------------------------------------------------
>
>                 Key: LUCENE-7863
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7863
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/index
>            Reporter: Mikhail Khludnev
>         Attachments: LUCENE-7863.hazard, LUCENE-7863.patch, 
> LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, 
> LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, 
> LUCENE-7863.patch, bench-byte-array-long.out, bench-byte-array2.out, 
> benchmark-1m.out, byterefshash-bench.txt
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes. 
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm 
> shuddering to think about EdgeNGrams...
> h2. Proposal 
> _DRY_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to