harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgeniya Maenkova (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-3089) [math] performance related improvements in java.math.BigDecimal/java.math.BigInteger/java.math.
Date Tue, 30 Jan 2007 15:41:33 GMT
[math] performance related improvements in java.math.BigDecimal/java.math.BigInteger/java.math.

                 Key: HARMONY-3089
                 URL: https://issues.apache.org/jira/browse/HARMONY-3089
             Project: Harmony
          Issue Type: Bug
          Components: Classlib
            Reporter: Evgeniya Maenkova
         Attachments: math.impr.patch

Several performance related proposals for java.math:
1) move Conversion.string2BigInteger(val, radix) to BigInteger. This method is called only
from BigInteger(String, int) . So if we move this into BigInteger redudant object will not
be created.
2) precision computation is pretty difficult, so (a) in inplaceRound we could add additional
check to use approx precision; (b) if BigDecimal is constructed from char[] we could compute
precision pretty cheaply.
3) as you know, if we work with small BigDecimals we use longs. Looks like this feature is
missed in  BigDecimal(char[], int, int). So let's keep this idea there also.
4) very small: let's use StringBuilder instead of StringBuffer in BigDecimal(char[] in, int
offset, int len).
We don't need such kind of synchronization there so let's use StringBuilder.
>From spec(StringBuffer): "As of release JDK 5, this class has been supplemented with an
equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class
should generally be used in preference to this one, as it supports all of the same operations
but it is faster, as it performs no synchronization. 
. "

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message