On Thu, 10 Oct 2024 07:32:15 GMT, fabioromano1 <d...@openjdk.org> wrote:
>> The class Javadoc mentions, in at least two places, that the two's >> complement representation conceptually has an infinite number of leading >> virtual sign bits. >> Once this point is clear, IMO the method's own Javadoc is then clear in >> turn. Maybe it could be improved as in "the bits that differ _in value_ from >> its sign bit". (Changing the spec requires another process and another, >> separate issue, but it can be done if needed.) > > @rgiulietti So it must have been my limitation, but I didn't realize it, even > though I knew that there are virtually infinite sign bits... Turns out that the table maintained by `expandBigIntegerTenPowers()` never stores more than 19 * 16 = 304 entries, totaling some 20 kB of resident storage in the worst case. Nor is the iterative multiplication by 10 a problem for such a small cache. I tried to reduce the size of the `FIVE_TO_2_TO` array to a length of 16 + 1 instead of 20. The size is then around 80 kB, about the same order of magnitude as for the cache above. The impact on performance is barely noticeable on large number of trailing zeros, with a slowdown of about 5%. Benchmark Mode Cnt Score Error Units BigDecimalStripTrailingZeros.testL avgt 15 2733190.412 ? 51858.195 ns/op BigDecimalStripTrailingZeros.testM avgt 15 9262.737 ? 18.105 ns/op BigDecimalStripTrailingZeros.testS avgt 15 153.792 ? 1.234 ns/op BigDecimalStripTrailingZeros.testXL avgt 15 466326466.667 ? 6076783.818 ns/op BigDecimalStripTrailingZeros.testXS avgt 15 21.336 ? 0.058 ns/op Finished running test 'micro:java.math.BigDecimalStripTrailingZeros' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1795735351
