[
https://issues.apache.org/jira/browse/LUCENE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828251#action_12828251
]
Paul Elschot commented on LUCENE-2232:
--------------------------------------
Yonik:
I searched for that past issue bit, it was probably LUCENE-639 on what was then
readVInt.
The issue was closed as won't fix, inconclusive.
One could conclude that it is probably not worthwhile to unroll the loop here,
I'll provide another
version of the patch for that.
Chris:
Indeed the hope is that for larger docs the amount of I/O will hardly increase.
It is good to know that readDeltaPosition spends 93% of time in readVInt when
using a disk.
It might well be that the C++ compiler used by Zhang is not as good in
preventing jumps that are difficult to predict
as the current Hotspot JIT.
That 93% in readVInt falling to 69% on SSD is a nice confirmation that moving
from disk to SSD makes
decoding speed more important.
Could you also measure how much time is spent in total in query search, for
example in IndexSearcher.search() ?
That would give an indication of an upperbound on the practical gain from this.
Aside: using PFOR for positions should also reduce reading time, and maybe disk
seeking time, too.
> Use VShort to encode positions
> ------------------------------
>
> Key: LUCENE-2232
> URL: https://issues.apache.org/jira/browse/LUCENE-2232
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Paul Elschot
> Attachments: LUCENE-2232-nonbackwards.patch,
> LUCENE-2232-nonbackwards.patch
>
>
> Improve decoding speed for typical case of two bytes for a delta position at
> the cost of increasing the size of the proximity file.
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
