[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803272#action_12803272
]
Renaud Delbru commented on LUCENE-1410:
---------------------------------------
{quote}
The only concern I have is that the instruction cache might get filled up with
the code for all these decoding cases.
At the moment I don't know how to deal with that other than by adding such
cases slowly while doing performance tests all the time.
{quote}
I am not very familiar with such technologies, and it is new to me to start
thinking of this kind of problems.
However, from what I understand in the WSDM slides about Google Group Varint
encoding, they are using a 256-entry table, which is much higher than the
49-107 cases you're proposing. From what I understand, the instruction cache
will be filled with such table, so it seems you have still some margin compared
to Group Varint encoding. Or is there other information that risks to be added
to the instruction cache ?
> 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
