You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Paul Elschot (JIRA)" <ji...@apache.org> on 2010/01/18 19:46:54 UTC
[jira] Issue Comment Edited: (LUCENE-2222)
FixedIntBlockIndexInput.Reader does not initialise 'pending' int array
[ https://issues.apache.org/jira/browse/LUCENE-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801895#action_12801895 ]
Paul Elschot edited comment on LUCENE-2222 at 1/18/10 6:45 PM:
---------------------------------------------------------------
ForDecompress.decodeAnyFrame() is pretty slow, it is mainly there as a fallback and I have also used it for testing initially.
For decoding blocks just shorter than 32, a few Simple9 blocks will be faster than ForDecompress.decodeAnyFrame().
Simple16 (4 bits for the cases, just as Simple9) would be good. I remember looking for a link to an implementation of Simple16 in one of the articles on Simple9, but the linked page had gone, so I just went ahead myself and started on Simple9.
One can also use 32 or 64 cases (5 or 6 bits for the cases) and allow a variable number of ints (or bytes) in such SimpleNN variants. Such variants nicely hit the middle ground between Simple9 and PFOR in block length and decoding speed. Perhaps we'd better continue the discussion on such methods at LUCENE-2189.
When there are sufficient methods available an issue could be opened for a general variable length block encoding/decoding that uses the best of such methods depending on the block length. This makes sense because in lucene indexes the block length is always known.
was (Author: paul.elschot@xs4all.nl):
ForDecompress.decodeAnyFrame() is pretty slow, it is mainly there as a fallback and I have also used it for testing initially.
For decoding blocks just shorter than 32, a few Simple9 blocks will be faster than vByte.
Simple16 (4 bits for the cases, just as Simple9) would be good. I remember looking for a link to an implementation of Simple16 in one of the articles on Simple9, but the linked page had gone, so I just went ahead myself and started on Simple9.
One can also use 32 or 64 cases (5 or 6 bits for the cases) and allow a variable number of ints (or bytes) in such SimpleNN variants. Such variants nicely hit the middle ground between Simple9 and PFOR in block length and decoding speed. Perhaps we'd better continue the discussion on such methods at LUCENE-2189.
When there are sufficient methods available an issue could be opened for a general variable length block encoding/decoding that uses the best of such methods depending on the block length. This makes sense because in lucene indexes the block length is always known.
> FixedIntBlockIndexInput.Reader does not initialise 'pending' int array
> ----------------------------------------------------------------------
>
> Key: LUCENE-2222
> URL: https://issues.apache.org/jira/browse/LUCENE-2222
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: Flex Branch
> Reporter: Renaud Delbru
> Priority: Minor
> Fix For: Flex Branch
>
> Attachments: LUCENE-2222.patch, LUCENE-2222.patch, LUCENE-2222.patch
>
>
> The FixedIntBlockIndexInput.Reader.pending int array is not initialised. As a consequence, the FixedIntBlockIndexInput.Reader#next() method returns always 0.
> A call to FixedIntBlockIndexInput.Reader#blockReader.readBlock() during the Reader initialisation may solve the issue (to be tested).
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org