RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
Raffaello Giulietti
rgiulietti at openjdk.org
Fri Oct 4 22:44:35 UTC 2024
On Fri, 4 Oct 2024 18:02:21 GMT, fabioromano1 <duke at 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
More information about the core-libs-dev
mailing list