You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2010/12/19 13:27:01 UTC

[jira] Issue Comment Edited: (LUCENE-2824) optimizations for bufferedindexinput

    [ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972975#action_12972975 ] 

Uwe Schindler edited comment on LUCENE-2824 at 12/19/10 7:26 AM:
-----------------------------------------------------------------

And as said in my above comment, for buffer sizes like 1024 or in that area (even for 16384 or like that), the overhead of throwing the AIOOBE would be much higher (as the JVM needs to generate stack trace!!!). I would simply don't even think about that *g*.

For MMap the idea is fine because we normally have "buffer" sizes of 2^31th, where the AIOOBE / BufferUnderflowEx is veeeeeeeeeeeery seldom.

      was (Author: thetaphi):
    And as said in my above comment, for buffer sizes like 1024 or in that are (even for 16384 or like that), the overhead of throwing the AIOOBE would be much higher (as the JVM needs to generate stack trace!!!). I would simply don't even think about that *g*.

For MMap the idea is fine because we normally have "buffer" sizes of 2^31th, where the AIOOBE / BufferUnderflowEx is veeeeeeeeeeeery seldom.
  
> optimizations for bufferedindexinput
> ------------------------------------
>
>                 Key: LUCENE-2824
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2824
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 3.1, 4.0
>            Reporter: Robert Muir
>         Attachments: LUCENE-2824.patch
>
>
> along the same lines as LUCENE-2816:
> * the readVInt/readVLong/readShort/readInt/readLong are not optimal here since they defer to readByte. for example this means checking the buffer's bounds per-byte in readVint instead of per-vint.
> * its an easy win to speed this up, even for the vint case: its essentially always faster, the only slower case is 1024 single-byte vints in a row, in this case we would do a single extra bounds check (1025 instead of 1024)

-- 
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org