lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2213) Small improvements to ArrayUtil.getNextSize
Date Fri, 15 Jan 2010 20:44:54 GMT

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

Michael McCandless commented on LUCENE-2213:
--------------------------------------------

Thanks Marvin, I fixed the typo.

I don't really like that test, since conceivably (though, unlikely) it could fail with a false
positive.

So I made a new test case (TestArrayUtil), which in fact uncovered serious problems with my
first patch, due to overflowing int!  Sigh.  I've fixed those problems and the test now passes.
 The test measures the amortized copying cost over a series of reallocations, and then [somewhat
arbitrarily] asserts that the cost per element is less than 10.0 through all reallocations
up to size Integer.MAX_INT.

Also I found one more place where we were assuming ArrayUtil.grow(X) returned the same value
regardless of type, which is no longer true.  Amazing how tricky such a low-level utility
function is....

> Small improvements to ArrayUtil.getNextSize
> -------------------------------------------
>
>                 Key: LUCENE-2213
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2213
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 3.1
>
>         Attachments: LUCENE-2213.patch, LUCENE-2213.patch
>
>
> Spinoff from java-dev thread "Dynamic array reallocation algorithms" started on Jan 12,
2010.
> Here's what I did:
>   * Keep the +3 for small sizes
>   * Added 2nd arg = number of bytes per element.
>   * Round up to 4 or 8 byte boundary (if it's 32 or 64 bit JRE respectively)
>   * Still grow by 1/8th
>   * If 0 is passed in, return 0 back
> I also had to remove some asserts in tests that were checking the actual values returned
by this method -- I don't think we should test that (it's an impl. detail).

-- 
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