lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Han Jiang (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4239) Provide access to PackedInts' low-level blocks <-> values conversion methods
Date Fri, 20 Jul 2012 15:55:34 GMT


Han Jiang commented on LUCENE-4239:

Thank you Adrien! We'll work easier with this Decoder/Encoder interface.

However, This patch isn't passing ant-compile under latest trunk, seems that encoder/decoder
methods for Packed64SingleBlockBulkOperation32 are missing? Anyway, we're not using docId
up to 32 bits currently, I'll test the performance later.

Since we have to handle IndexInput/Output at upper level, we prefer to use direct int[] rather
than IntBuffer. Actually, we had a patch making PackedIntsDecompress handle int array instead:
(the file name was Performance test shows little difference between
these two versions, but as int[] is clear and simple, I think that should be what we hope
to use.

So... maybe you can provide us methods like: encode(int[] values, long[] blocks, int iterations),
decode(long[] blocks, int[] values, int iterations)? 
> Provide access to PackedInts' low-level blocks <-> values conversion methods
> ----------------------------------------------------------------------------
>                 Key: LUCENE-4239
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/other
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>            Priority: Minor
>             Fix For: 4.0
>         Attachments: LUCENE-4239.patch
> In LUCENE-4161 we started to make the {{PackedInts}} API more flexible so that codecs
could use it whenever they need to (un)pack integers. There are two posting formats in progress
(For and PFor, LUCENE-3892) that perform a lot of integer (un)packing but the current API
still has limits :
>  - it only works with long[] arrays, whereas these codecs need to manipulate int[] arrays,
>  - the packed reader iterators work great for unpacking long sequences of integers, but
they would probably cause a lot of overhead to decode lots of short integer sequences such
as the ones that can be generated by For and PFor.
> I've been looking at the For/PFor branch and it has a {{PackedIntsDecompress}} class
which is very similar to {{oal.util.packed.BulkOperation}} (package-private), so maybe we
should find a way to expose this class so that the For/PFor branch can directly use it.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message