On Fri, 4 Oct 2024 18:02:21 GMT, fabioromano1 <d...@openjdk.org> wrote:
>> It takes around 100 ms and less than 1 MB to build a table up to 20 rather
>> than 29.
>> It can be fully constructed in `static { ... }`, avoiding races.
>>
>> IMO, this would cover the vast majority of the cases encountered in practice.
>> Other, way less common usages with multi-millions or billions of digits
>> would then impact running time but not _persistent_ memory footprint.
>>
>> WDYT?
>
> @rgiulietti Though, it's also true that if I want to do astronomical
> calculations, I probably have a machine that allows me to do so, and so I'd
> like to be able to make the most of it...
`BigDecimal` was not designed to do astronomical computations. One would
probably use other libraries for that, e.g., [GMP](https://gmplib.org/) and
would not be interested too much in "stripping trailing zeros".
The focus of this class is mainly commercial applications, where decimal
arithmetic is sometimes mandated by regulators.
So I'd expect that most usages, for example SQL or commercial application
workloads, will process numbers with a few dozens of digits, maybe sometimes
some hundreds digits for intermediate results. So I think that accelerating for
these sizes makes the most practical sense.
With modest memory and CPU costs, I think even one million digits or so might
be processed reasonably fast.
My point is that there's room for improvement in these range of sizes, but
perhaps not for larger ones.
More importantly, though, I'd like to avoid one single computation to affect
the resident memory footprint of a JVM instance for its entire lifetime.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788393701
