[
https://issues.apache.org/jira/browse/LUCENE-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399883#comment-13399883
]
Han Jiang edited comment on LUCENE-3892 at 8/8/12 3:41 AM:
-----------------------------------------------------------
Yes, really interesting. And that should make sense. -As far as I know, a
method with exception handling may be quite slow than a simple if statement
check.-(Hmm, now I think this is not true, the improvement should mainly come
the framework change) Here is part of the result in my test, with Mike's patch:
{noformat}
OrHighMed 2.53 0.31 2.57 0.13 -13% -
21%
Wildcard 3.86 0.12 3.94 0.38 -10% -
15%
OrHighHigh 1.57 0.18 1.61 0.08 -12% -
21%
TermBGroup1M1P 1.93 0.03 2.48 0.10 21% -
35%
TermGroup1M 1.37 0.02 1.81 0.05 26% -
37%
TermBGroup1M 1.17 0.02 1.64 0.07 32% -
47%
Term 2.92 0.13 4.46 0.23 38% -
68%
{noformat}
was (Author: billy):
Yes, really interesting. And that should make sense. As far as I know, a
method with exception handling may be quite slow than a simple if statement
check. Here is part of the result in my test, with Mike's patch:
{noformat}
OrHighMed 2.53 0.31 2.57 0.13 -13% -
21%
Wildcard 3.86 0.12 3.94 0.38 -10% -
15%
OrHighHigh 1.57 0.18 1.61 0.08 -12% -
21%
TermBGroup1M1P 1.93 0.03 2.48 0.10 21% -
35%
TermGroup1M 1.37 0.02 1.81 0.05 26% -
37%
TermBGroup1M 1.17 0.02 1.64 0.07 32% -
47%
Term 2.92 0.13 4.46 0.23 38% -
68%
{noformat}
> Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta,
> Simple9/16/64, etc.)
> -------------------------------------------------------------------------------------
>
> Key: LUCENE-3892
> URL: https://issues.apache.org/jira/browse/LUCENE-3892
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Labels: gsoc2012, lucene-gsoc-12
> Fix For: 4.1
>
> Attachments: LUCENE-3892-BlockTermScorer.patch,
> LUCENE-3892-blockFor&hardcode(base).patch,
> LUCENE-3892-blockFor&packedecoder(comp).patch,
> LUCENE-3892-blockFor-with-packedints-decoder.patch,
> LUCENE-3892-blockFor-with-packedints-decoder.patch,
> LUCENE-3892-blockFor-with-packedints.patch,
> LUCENE-3892-direct-IntBuffer.patch, LUCENE-3892-for&pfor-with-javadoc.patch,
> LUCENE-3892-handle_open_files.patch,
> LUCENE-3892-pfor-compress-iterate-numbits.patch,
> LUCENE-3892-pfor-compress-slow-estimate.patch, LUCENE-3892_for_byte[].patch,
> LUCENE-3892_for_int[].patch, LUCENE-3892_for_unfold_method.patch,
> LUCENE-3892_pfor_unfold_method.patch, LUCENE-3892_pulsing_support.patch,
> LUCENE-3892_settings.patch, LUCENE-3892_settings.patch
>
>
> On the flex branch we explored a number of possible intblock
> encodings, but for whatever reason never brought them to completion.
> There are still a number of issues opened with patches in different
> states.
> Initial results (based on prototype) were excellent (see
> http://blog.mikemccandless.com/2010/08/lucene-performance-with-pfordelta-codec.html
> ).
> I think this would make a good GSoC project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
