[
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: [email protected]):
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: [email protected]
For additional commands, e-mail: [email protected]
