[
https://issues.apache.org/jira/browse/LUCENE-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014929#comment-14014929
]
Michael McCandless commented on LUCENE-5722:
--------------------------------------------
+1 to specialize the single buffer case again.
Does the optimization only kick in when the entire .dat (holding doc values for
all fields in this segment) is less than MMapDir's chunk size? Ie, we don't
use IndexInput.slice from our doc values impls today (at least for the default,
Lucene45DVF). We just do .clone(), which in ByteBufferIndexInput is a slice of
the whole file.
Also, if you get unlucky, the .dat could be smallish but span 2 chunks anyway,
e.g. if that segment used CFS format, and then specialization doesn't kick in,
right?
> Speed up MMapDirectory.seek()
> -----------------------------
>
> Key: LUCENE-5722
> URL: https://issues.apache.org/jira/browse/LUCENE-5722
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-5722.patch
>
>
> For traditional lucene access which is mostly sequential, occasional
> advance(), I think this method gets drowned out in noise.
> But for access like docvalues, its important. Unfortunately seek() is complex
> today because of mapping multiple buffers.
> However, the very common case is that only one map is used for a given clone
> or slice.
> When there is the possibility to use only a single mapped buffer, we should
> instead take advantage of ByteBuffer.slice(), which will adjust the internal
> mmap address and remove the offset calculation. furthermore we don't need the
> shift/mask or even the negative check, as they are then all handled with the
> ByteBuffer api: seek is a one-liner (with try/catch of course to convert
> exceptions).
> This makes docvalues access 20% faster, I havent tested conjunctions or
> anyhting like that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
