[
https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972980#action_12972980
]
Robert Muir commented on LUCENE-2824:
-------------------------------------
{quote}
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.
{quote}
Ok, i looked into this and I think I agree with Uwe.
I'm concerned about the JRE-specifics here too (cost of an exception, for
example I ran all the tests on IKVM jvm the other day,
and a wierd one failed due to this:
http://weblog.ikvm.net/CommentView.aspx?guid=062e4506-89c4-488e-9104-59c1ec80007b
So, I think the optimization here (reducing checks on average) is safe, but I'm
worried about going the exception route with
such a small buffer... even if we could tweak it out to perform better on a sun
JRE,
> 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: [email protected]
For additional commands, e-mail: [email protected]
