[ https://issues.apache.org/jira/browse/LUCENE-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972880#action_12972880 ]
Robert Muir commented on LUCENE-2816: ------------------------------------- committed revision 1050737. I'll wait a bit for branch_3x. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org