[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833922#action_12833922
]
Renaud Delbru commented on LUCENE-1410:
---------------------------------------
{quote}
In general the frameBitsForCompression() method should try and find the number
that has the quickest decompression.
{quote}
In fact, the method is trying to find the configuration that has the smaller
size in term of bytes (with the test totalBytes <= bestBytes). But it seems
that it is not always the best case for quick decompression. I haven't test the
decompression speed of PFOR yet, but I imagine that with 89% of exceptions
(while in the original algorithm exception should occurs only a few times), it
should not be the best performance.
Why not just computing the index (in the sorted copy array) that will represent
the percentage of values that should be packed, and the remaining of the array
encoded as exceptions ?
> 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
