harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Strigun" <vstri...@gmail.com>
Subject [classlib][java.math]performance improvement for java.math package
Date Fri, 02 Jun 2006 07:54:24 GMT
Our team has done some analysis of current Harmony implementation of
java.math package. The implementation was considered from the
performance point of view and I'd like to share results of our work
with you.

The analysis and tuning was made from the enterprise-level
applications point of view which are known to use BigInteger and
BigDecimal for storing numeric information. In most cases the numbers
there fit well within 32 bits. So coming from the BigDecimal
perspective which is really important for these applications and
taking into account some specifics (small numbers) we made some
optimizations in both BigDecimal and BigInteger. The latter was tuned
specifically for BigDecimal:

- Special handling for small numbers (fit within 32 bit) was added to
all methods
- Frequently used constants (0..10) were cached and reused by valueOf
method (no need to create a new instance of BigInteger)
- as well as were powers of 10 (0..10)
- methods add(), divide(), divideAndRemainer() in BigInteger were
optimized for short values if both arguments can fit in 32 bits the
resulting BigInteger is created  by valueOf method.


If we consider enterprise level applications, we can imagine that
toString() method is also frequently used. The method was analyzed and
as a result we combined toString() methods in BigDecimal and
BigInteger to one unified method in BigInteger. Method
BigInteger.toDecimalScaledString(int scale) now  is used from  both
BigInteger and BigDecimal.  This way allows reducing amount of created
objects and data copying. In addition, size calculation was modified
for resulting array. In the new implementation the size is calculated
with less precision. Because allocated char array will be copied into
String and collected by GC after toString() then it is not a problem
if the allocated char array will be slightly bigger then necessary.

I've attached the changes we made for BigInteger and BigDecimal to Harmony-551

We also have created a set of micro benchmarks (which I'll to attach
to JIRA as well) which shows that our special-case handling doesn't
break the performance for other cases and we do not degrade in common,
and, of course, all unit tests pass with new version. Below you can
find several comparisons in performance between current version and
the fixed one.

===

Ops/sec for toString() method of BigDecimal

Number     Current       fixed one
of digits     version
2       1121    5354
4       774     7514
8       615     6748
12      743     5543
16      623     4494
24      389     4895
32      306     3496
48      232     5815
64      224     3761
128     91      87

Ops/sec for divide method of BigInteger

Number     Current       fixed one
of digits     version

2       5247    6315
4       4623    6497
8       5560    7491
12      838     838
16      2533    2063
24      1689    1717
32      2397    2494
48      2143    2131
64      613     525
128     1399    1418

Ops/sec for subtract method of BigInteger

Number     Current       fixed one
of digits     version

2       3920    4394
4       3300    3302
8       5178    5640
12      957     913
16      3794    2904
24      2057    1962
32      3421    3241
48      3469    2828
64      652     610
128     2318    2246

===

Unfortunately we haven't look thoroughly to ITC contribution, so it
may happen that some of the optimizations described in this letter
were already implemented there. Daniel, could you please consider our
new implementation when you start to merge implementations math
packages. If optimization methods described above already have been
implemented in ITC contribution it will be great to compare internal
representation of BigInteger and try to measure affect of different
approaches.




On 6/2/06, Vladimir Strigun (JIRA) <jira@apache.org> wrote:
>     [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ]
>
> Vladimir Strigun updated HARMONY-551:
> -------------------------------------
>
>    Attachment: Harmony-551.diffs
>
> Please try my patch.
> Several features were added:
> - special handling for small value
> - frequently used constans were cached
> - several methods were modified and optimized for small value.
> etc.
>
> > [classlib][java.math] performance improvement for java.math package
> > -------------------------------------------------------------------
> >
> >          Key: HARMONY-551
> >          URL: http://issues.apache.org/jira/browse/HARMONY-551
> >      Project: Harmony
> >         Type: Improvement
>
> >   Components: Classlib
> >     Reporter: Vladimir Strigun
> >  Attachments: Harmony-551.diffs
> >
> > Performance improvement for BigDecimal and BigInteger classes.
> > I will attach patch soon.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>   http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>   http://www.atlassian.com/software/jira
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message