[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833895#action_12833895
]
Paul Elschot commented on LUCENE-1410:
--------------------------------------
That might indeed be a bug.
In general the frameBitsForCompression() method should try and find the number
that has the quickest decompression.
The trade off is between exceptions taking extra time, and a smaller number of
frame bits taking less time.
I have not timed the exception decoding yet, so I would not expect the current
implementation of frameBitsForCompression() to be right on the spot.
Please note that I'd still like to change the exception encoding, see the
comment of 12 May 2009:
"For an exception, we store its lower b bits instead of the offset to the next
exception in its corresponding slot, while we store the higher overflow bits
and the offset in two separate arrays. These two arrays are compressed using
the Simple16 method."
> PFOR implementation
> -------------------
>
> Key: LUCENE-1410
> URL: https://issues.apache.org/jira/browse/LUCENE-1410
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Other
> Reporter: Paul Elschot
> Priority: Minor
> Attachments: autogen.tgz, LUCENE-1410-codecs.tar.bz2,
> LUCENE-1410b.patch, LUCENE-1410c.patch, LUCENE-1410d.patch,
> LUCENE-1410e.patch, TermQueryTests.tgz, TestPFor2.java, TestPFor2.java,
> TestPFor2.java
>
> Original Estimate: 21840h
> Remaining Estimate: 21840h
>
> Implementation of Patched Frame of Reference.
--
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
