[ 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