RFR: 8341402: BigDecimal's square root optimization

[Raffaello Giulietti]

On Mon, 21 Oct 2024 17:01:43 GMT, fabioromano1 <duke at openjdk.org> wrote:

>>> > Curiously, this one runs in a fraction of a second on the current implementation, but not on the proposed one: `BigDecimal.valueOf(100).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN)).shortValue()`
>>> 
>>> @rgiulietti This is because, in the current implementation, the check for even powers of 10 is always done, while in mine is done only if exact result is required.
>> 
>> Since there's an invocation of `stripTrailingZeros()` anyway, what's the reason to _not_ "optimize" for other round modes as well, like in the current implementation?
>
>> Since there's an invocation of `stripTrailingZeros()` anyway, what's the reason to _not_ "optimize" for other round modes as well, like in the current implementation?
> 
> Because it is not necessary to strip zeros when an exact result is not requested, so while the call to `stripTrailingZeros()` speeds up only for the unlikely case that the input is an even power of 10, it slows down for all other cases...

@fabioromano1 I took a look at the code, and at first sight it looks good.
However, before approving, I'll have a deeper look in the next couple of days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2474053522