lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Toke Eskildsen (JIRA)" <>
Subject [jira] Commented: (LUCENE-1990) Add unsigned packed int impls in oal.util
Date Tue, 06 Apr 2010 20:09:34 GMT


Toke Eskildsen commented on LUCENE-1990:

I did a checkout with
svn co lucene-flex

and added the following method to TestPackedInts

  public void testSecondaryBlockChange() throws IOException {
    PackedInts.Mutable mutable = new Packed64(26, 5);
    mutable.set(24, 31);
    assertEquals("The value #24 should be correct", 31, mutable.get(24));
    mutable.set(4, 16);
    assertEquals("The value #24 should remain unchanged", 31, mutable.get(24));

after which I ran

ant test-core

which gave me

    [junit] Testsuite: org.apache.lucene.util.packed.TestPackedInts
    [junit] Testcase: testSecondaryBlockChange(org.apache.lucene.util.packed.TestPackedInts):
    [junit] The value #24 should remain unchanged expected:<31> but was:<28>
    [junit] junit.framework.AssertionFailedError: The value #24 should remain unchanged expected:<31>
but was:<28>
    [junit] 	at org.apache.lucene.util.packed.TestPackedInts.testSecondaryBlockChange(
    [junit] 	at org.apache.lucene.util.LuceneTestCase.runBare(

then I added

              if (bitPos <= BLOCK_SIZE - elementBits) { // Second block not used
                currentMasks[base+1] = ~0; // Keep all bits
                currentMasks[base+2] = 0;  // Or with 0

to the relevant parts of Packed32 and Packed, as described above and ran

ant test-core

again, which gave me

    [junit] Testsuite: org.apache.lucene.util.packed.TestPackedInts
    [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 5.463 sec

My initial unit-test contained an error, which I corrected after a minute or two (as far as
I remember). Maybe you used the first version?

It seems that the bug is indeed in trunk. It corrupts the value of the block after the current
block in certain cases: Sequential assignment of values works fine, but out-of-order assignments
corrupts the array.

> Add unsigned packed int impls in oal.util
> -----------------------------------------
>                 Key: LUCENE-1990
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>    Affects Versions: Flex Branch
>            Reporter: Michael McCandless
>            Priority: Minor
>             Fix For: Flex Branch
>         Attachments: generated_performance-te20100226.txt, LUCENE-1990-te20100122.patch,
LUCENE-1990-te20100210.patch, LUCENE-1990-te20100212.patch, LUCENE-1990-te20100223.patch,
LUCENE-1990-te20100226.patch, LUCENE-1990-te20100226b.patch, LUCENE-1990-te20100226c.patch,
LUCENE-1990-te20100301.patch, LUCENE-1990.patch, LUCENE-1990.patch, LUCENE-1990.patch,,
perf-mkm-20100227.txt, performance-20100301.txt, performance-te20100226.txt
> There are various places in Lucene that could take advantage of an
> efficient packed unsigned int/long impl.  EG the terms dict index in
> the standard codec in LUCENE-1458 could subsantially reduce it's RAM
> usage.  FieldCache.StringIndex could as well.  And I think "load into
> RAM" codecs like the one in TestExternalCodecs could use this too.
> I'm picturing something very basic like:
> {code}
> interface PackedUnsignedLongs  {
>   long get(long index);
>   void set(long index, long value);
> }
> {code}
> Plus maybe an iterator for getting and maybe also for setting.  If it
> helps, most of the usages of this inside Lucene will be "write once"
> so eg the set could make that an assumption/requirement.
> And a factory somewhere:
> {code}
>   PackedUnsignedLongs create(int count, long maxValue);
> {code}
> I think we should simply autogen the code (we can start from the
> autogen code in LUCENE-1410), or, if there is an good existing impl
> that has a compatible license that'd be great.
> I don't have time near-term to do this... so if anyone has the itch,
> please jump!

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:
For additional commands, e-mail:

View raw message