[
https://issues.apache.org/jira/browse/LUCENE-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972418#action_12972418
]
Robert Muir commented on LUCENE-2816:
-------------------------------------
bq. I just wanted to be sure that the position pointer in the buffer does not
partly go forward when you read request fails at a buffer boundary, but that
seems to be the case.
Yes, this is guaranteed in the APIs, and also tested well by TestMultiMMap,
which uses random chunk sizes between 20 and 100 (including odd numbers etc)
Though we should enhance this test, i think it just retrieves documents at the
moment... probably better if it did some searches too.
> MMapDirectory speedups
> ----------------------
>
> Key: LUCENE-2816
> URL: https://issues.apache.org/jira/browse/LUCENE-2816
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 3.1, 4.0
> Reporter: Robert Muir
> Assignee: Robert Muir
> Attachments: LUCENE-2816.patch
>
>
> MMapDirectory has some performance problems:
> # When the file is larger than Integer.MAX_VALUE, we use MultiMMapIndexInput,
> which does a lot of unnecessary bounds-checks for its buffer-switching etc.
> Instead, like MMapIndexInput, it should rely upon the contract of these
> operations
> in ByteBuffer (which will do a bounds check always and throw
> BufferUnderflowException).
> Our 'buffer' is so large (Integer.MAX_VALUE) that its rare this happens and
> doing
> our own bounds checks just slows things down.
> # the readInt()/readLong()/readShort() are slow and should just defer to
> ByteBuffer.readInt(), etc
> This isn't very important since we don't much use these, but I think there's
> no reason
> users (e.g. codec writers) should have to readBytes() + wrap as bytebuffer +
> get an
> IntBuffer view when readInt() can be almost as fast...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
