On Tue, Jan 12, 2010 at 6:27 PM, Marvin Humphrey <mar...@rectangular.com> wrote:
> return (targetSize >> 3) + (targetSize < 9 ? 3 : 6) + targetSize;
>
> For input values of 9 or greater, all that formula does is multiply by 1.125
> and add 6. (Values enumerated below my sig.)
>
> The comment appears to have originated with this Python commit:
Yeah, something highly optimized for python in C may not be optimal for Java.
[...]
> IMO, just overallocating by some multiplier between 1.125 and 1.5 achieves our
> primary goal of avoiding pathological reallocation behavior, and that's
> enough.
> How about simplifying ArrayUtil.getNextSize() down to this?
>
> return targetSize + (targetSize / 8);
Seems like the right thing is highly dependent on the use case. But
rounding the final result always seems like a good idea? Of course
you need to know what the data type is to really optimize the round.
Solr contains the following code:
// We avoid a doubling strategy to lower memory usage.
// this faceting method isn't for docs with many terms.
// In hotspot, objects have 2 words of overhead, then
fields, rounded up to a 64-bit boundary.
// TODO: figure out what array lengths we can round up
to w/o actually using more memory
// (how much space does a byte[] take up? Is data
preceded by a 32 bit length only?
// It should be safe to round up to the nearest 32 bits
in any case.
int newLen = (newend + 3) & 0xfffffffc; // 4 byte alignment
In this case, the number of byte arrays temporarily being managed can
be maxDoc (in the very worst case) so it's critical not to waste any
space.
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
