Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <10917503.1170171693994.JavaMail.jira@brutus>
Date: Tue, 30 Jan 2007 07:41:33 -0800 (PST)
From: "Evgeniya Maenkova (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Created: (HARMONY-3089) [math] performance related
 improvements in java.math.BigDecimal/java.math.BigInteger/java.math.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

[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.