You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Evgeniya Maenkova (JIRA)" <ji...@apache.org> on 2007/01/30 16:41:33 UTC
[jira] Created: (HARMONY-3089) [math] performance related
improvements in java.math.BigDecimal/java.math.BigInteger/java.math.
[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.
[jira] Updated: (HARMONY-3089) [math] performance related
improvements in java.math.BigDecimal/java.math.BigInteger/java.math.
Posted by "Evgeniya Maenkova (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evgeniya Maenkova updated HARMONY-3089:
---------------------------------------
Attachment: math.impr.patch
patch with improvements mentioned in the description
> [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.
[jira] Closed: (HARMONY-3089) [math] performance related
improvements in java.math.BigDecimal/java.math.BigInteger/java.math.
Posted by "Evgeniya Maenkova (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evgeniya Maenkova closed HARMONY-3089.
--------------------------------------
Thanks, Alexey: works fine.
> [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
> Assigned To: Alexey Petrenko
> 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.
[jira] Assigned: (HARMONY-3089) [math] performance related
improvements in java.math.BigDecimal/java.math.BigInteger/java.math.
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko reassigned HARMONY-3089:
----------------------------------------
Assignee: Alexey Petrenko
> [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
> Assigned To: Alexey Petrenko
> 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.
[jira] Commented: (HARMONY-3089) [math] performance related
improvements in java.math.BigDecimal/java.math.BigInteger/java.math.
Posted by "Evgeniya Maenkova (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469371 ]
Evgeniya Maenkova commented on HARMONY-3089:
--------------------------------------------
License granted to ASF for inclusion in ASF works (as per the Apache Software License ยง5).
> [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
> Assigned To: Alexey Petrenko
> 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.
[jira] Resolved: (HARMONY-3089) [math] performance related
improvements in java.math.BigDecimal/java.math.BigInteger/java.math.
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko resolved HARMONY-3089.
--------------------------------------
Resolution: Fixed
The patch has been applied, please verify.
> [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
> Assigned To: Alexey Petrenko
> 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.