[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[
https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984326#action_12984326
]
Michael McCandless commented on LUCENE-2824:
I'm seeing excellent gains w/ this patch, on Linux 64bit Java 6 NIOFSDir:
||Query||QPS clean||QPS robspec||Pct diff
|spanFirst(unit, 5)|16.67|15.62|{color:red}-6.3%{color}|
|"unit state"|8.04|7.87|{color:red}-2.2%{color}|
|spanNear([unit, state], 10, true)|4.31|4.25|{color:red}-1.2%{color}|
|"unit state"~3|4.85|5.02|{color:green}3.6%{color}|
|unit state|10.35|10.94|{color:green}5.7%{color}|
|unit~1.0|9.60|10.15|{color:green}5.7%{color}|
|unit~2.0|9.35|9.94|{color:green}6.3%{color}|
|united~2.0|3.30|3.51|{color:green}6.4%{color}|
|+nebraska +state|161.71|174.23|{color:green}7.7%{color}|
|+unit +state|11.20|12.09|{color:green}8.0%{color}|
|doctitle:.*[Uu]nited.*|3.93|4.25|{color:green}8.0%{color}|
|united~1.0|15.12|16.39|{color:green}8.4%{color}|
|un*d|49.33|56.09|{color:green}13.7%{color}|
|u*d|14.85|16.97|{color:green}14.3%{color}|
|state|25.95|30.12|{color:green}16.1%{color}|
|unit*|22.72|26.88|{color:green}18.3%{color}|
|uni*|12.64|15.20|{color:green}20.2%{color}|
|doctimesecnum:[1 TO 6]|8.42|10.73|{color:green}27.4%{color}|
+1 to commit.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[
https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973783#action_12973783
]
Robert Muir commented on LUCENE-2824:
-
{quote}
Do these performance comparison tests (posted on 19 December above) have a
basic verification that each query returns the same result, for example a CRC
on the matching docids and perhaps also a CRC on the score values?
{quote}
Yes, the performance benchmark I used originally came from Mike, it builds on
contrib/benchmark, you can see it here: http://code.google.com/p/luceneutil/
It verifies as you suggested, and in fact has found bugs before that our tests
don't find... which frustrates me about our unit tests!
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973735#action_12973735 ] Paul Elschot commented on LUCENE-2824: -- Do these performance comparison tests (posted on 19 December above) have a basic verification that each query returns the same result, for example a CRC on the matching docids and perhaps also a CRC on the score values? > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973177#action_12973177 ] Robert Muir commented on LUCENE-2824: - Paul I agree with your sentiments, for this issue I'd like to stick with this patch as just a small step (reducing bounds checks on average). In general, I think its probably the case we can improve our i/o (especially BufferedIndexInput) to be more efficient with the int block codecs, don't hesitate to open more issues if there are ideas, I've definitely been testing a lot of crazy things, but the others didn't pan out :) > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972981#action_12972981 ] Paul Elschot commented on LUCENE-2824: -- In case I understood the javaspecialists article correctly, it could be faster to use AIOOBE but only when -XX:-OmitStackTraceInFastThrow is not used in the sun/oracle jvm. For the first few hundreds of exceptions from the same piece of code however it would always be slower. Since this depends on the JVM I'd rather keep the explicit bounds check in the code for now, and may be open a separate issue when it turns out to be faster to use AIOOBE. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972977#action_12972977 ] Paul Elschot commented on LUCENE-2824: -- It's too long ago that I had to deal with this tradeoff myself, so I'm taking a look here: http://www.javaspecialists.eu/archive/Issue187.html "Cost of causing exceptions" (2010-08-31). > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (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 commented on LUCENE-2824: --- 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 vry 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972974#action_12972974 ] Robert Muir commented on LUCENE-2824: - well its slightly trickier to do it this way (e.g. slimming down the array in the very special case but restoring the fully sized one later in a future refill(), but potentially worthwhile... we should at least benchmark the exception idea, and see how it goes. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972973#action_12972973 ] Paul Elschot commented on LUCENE-2824: -- You are obviously more familiar with the code than me :) > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972971#action_12972971 ] Robert Muir commented on LUCENE-2824: - oh, i think i see your idea Paul... so in the special case when we refill() at the end of the file and we populate less than the buffers length, we just have to copy to a shorter array so this will work? > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972972#action_12972972 ] Paul Elschot commented on LUCENE-2824: -- Using bounds check would be possible when the array size equals the buffered size. But indeed this need not normally be the case. I'll take a closer look, it might be worthwhile to use a smaller array object when there is no more data available. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972968#action_12972968 ] Robert Muir commented on LUCENE-2824: - bq. Did you also try to catch out of bounds exceptions instead of doing the bounds checks in the current patch? Paul, how can we do this? In the mmap case we can because the mmap getXXX will throw the bufferunderflow and not actually read anything if there isn't enough bytes. But in this case I don't see how we can re-arrange the code to safely do this? if you know, please let us know as I think this would be better too. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972969#action_12972969 ] Uwe Schindler commented on LUCENE-2824: --- For the MMap case with *vry* large arrays, the cost of exception instantiation with stack trace is really small. I think for small buffer sizes like 1024 the overhead would be immense. But we should check this :-) Another place where the checks were omitted and instead AIOOBE is catched is FieldCacheRangeFilter. This really helps there! But in that case FieldCache is always large :-) > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972967#action_12972967 ] Paul Elschot commented on LUCENE-2824: -- Did you also try to catch out of bounds exceptions instead of doing the bounds checks in the current patch? > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972966#action_12972966 ] Robert Muir commented on LUCENE-2824: - sorry my math was off, the worst case is 4 extra checks (1028 total?)... but in general the buffer size default (1024) is large enough that this helps. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2824) optimizations for bufferedindexinput
[ https://issues.apache.org/jira/browse/LUCENE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972965#action_12972965 ] Uwe Schindler commented on LUCENE-2824: --- +1, Thats a good idea overall: Always optimize the general case (buffer is large enough), and fallback if not > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
