Hi,
Please don't commit this.
+ if (!value && startIdx >= datalen) {
+ return;
+ }
return? First I tought it's a bug. Please add a comment saying 'trying
to clear something that's already cleared - nothing to do'.
- // go backwards so that OutOfMemory happens
- // before some bytes are modified
+ //Expand BitField if writing past end, unless clearing
+ //Prevents OutOfMemoryError mid-modify
Please use my comment format (one space after '//', lowercase)
+ public void setRange(final int start, final int len, final boolean value) {
Please don't use 'final' in parameters and local variables. I never
did except where necessary. It clutters the code. Unless you can prove
it's faster (and I would need a hard prove).
+ final int startIdx = start >> ADDRESS_BITS;
Please use getAddress. I hate copy & pasted code.
> Math.max(start, start + len - 1)
That's not necessary if len is always larger than 0. The method should
be able to deal with len <= 0, maybe throw an exception or ignore it,
but not do something 'wrong'.
+ java.util.Arrays.fill
Please use import.
+ final long setVal = value ? 0xFFFFFFFFFFFFFFFFL : 0;
+ java.util.Arrays.fill(data, startIdx + 1, endIdx, setVal);
Instead, use:
+ Arrays.fill(data, startIdx + 1, endIdx, value ? -1 : 0);
Regards,
Thomas
On Fri, Aug 7, 2009 at 12:44 AM, Sam Van Oort<[email protected]> wrote:
> Update:
> Testing passed, and the new code is a LOT faster. Whenever Thomas gives me
> the go-ahead (I've emailed details to him) I'll commit the changes.
> For the moment, but here is a teaser for you all:
>
> *** Unpatched (using previous stable build): ***
> Sequential set range (ms): (64 bits / 500 bits / 5000 bits)
> 5.31 / 39.1 / 377.5
>
> Random set range (ms): (max 64 bits / 500 bits / 5000 bits)
> 488 / 2519 / 22404
>
> *** PATCHED:***
> Unpatched (using previous stable build):
> Sequential set range (ms): (64 bits / 500 bits / 5000 bits)
> 0.373 / 0.500 / 3.52
>
> Random set range (ms): (max 64 bits / 500 bits / 5000 bits)
> 217 / 254 / 356
>
> Yes that's right, the patch makes BitField.setRange between 10 and 100 (!!!)
> times faster. In the bigger picture, this should improve performance a bit
> in many different places. In particular, index creation with large rows
> should be faster. Based on profiling of index creation, there aren't many
> (simple) bottlenecks, but this is a one minor one, and every small
> optimization will help!
>
> The only case when the old method is faster is for VERY small ranges -- 3
> bits or less, from what I'm seeing.
> If that's a problem, I believe I can improve that; don't want to re-test and
> re-benchmark unless I have to though.
>
> Cheers,
> Sam Van Oort
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en
-~----------~----~----~----~------~----~------~--~---
