lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/LUCENE-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854151#action_12854151
] 

Toke Eskildsen commented on LUCENE-1990:
----------------------------------------

I did a checkout with
{code}
svn co https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene lucene-flex
{code}

and added the following method to TestPackedInts

{code}
  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));
  }
{code}

after which I ran

{code}
ant test-core
{code}

which gave me

{code}
    [junit] Testsuite: org.apache.lucene.util.packed.TestPackedInts
    [junit] Testcase: testSecondaryBlockChange(org.apache.lucene.util.packed.TestPackedInts):
FAILED
    [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(TestPackedInts.java:106)
    [junit] 	at org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:276)
{code}

then I added

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

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

{code}
ant test-core
{code}

again, which gave me

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

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: https://issues.apache.org/jira/browse/LUCENE-1990
>             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, LUCENE-1990_PerformanceMeasurements20100104.zip,
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message