On Oct 16, 2007, at 4:32 PM, Charles Miller wrote:
3) Immutable objects are less efficient than mutable ones... but
most of the time you don't care.
Object allocation in Java is distressingly cheap. Garbage-
collection of young generation objects is reasonably inexpensive.
The Java language is _designed_ with the creation and destruction
of lots of little objects in mind, and it does it very well. As
such, it makes sense to err on the side of creating too many objects.
There are, of course, exceptions. That's why we profile code. For
the most common case where immutability can be a problem --
building strings -- Java offers a mutable StringBuilder. This is a
pretty common pattern: offer a builder class to construct objects
piecemeal, then have the immutable value pop out of the other end.
You've found a case where the immutable bignum classes in Java
aren't efficient enough for you, and the only alternative you have
is to abandon them and mess with arrays. The problem here isn't
that BigInteger and BigDecimal are immutable, having them be
immutable is the Right Thing To Do. The real problem is that
providing a high-performance library for arbitrary precision
arithmetic would _also_ be the Right Thing To Do, but Java doesn't.
Fwiw, some of my test results...
Reported speed, ms I believe
BC 9029, 8873, 8884, 8939, 8740
Olaf's 8982, 8750, 8780, 8692,8764
Mine 8267, 7619, 8150, 7912, 7960
BC is a released version of the code (ECDH key exchanges). Olaf's
the optimized algorithm BigInteger version I showed earlier, mine
the byte[] mutable version I showed.
run -Xloggc
(Showing the reported result time, # of GC's in log, totaled log
elapsed time and totaled log GC time)
BC
10597 565 GC's 12.104 0.824896
9871 563 11.351 0.772
10002 559 11.5 .80199
10173 567 11.668 .810
10879 572 12.45 .818
Olaf's
12387 615 14.138 0.812
11326 621 13.077 0.823
11140 612 12.616 0.820
10750 607 12.237 0.827
11073 609 12.576 0.805
Mine
9006 506 10.485 .7399
9101 511 10.565 .7538
8988 505 10.457 .730
9056 506 10.542 .790
10015 505 11.591 .808
I've been taking the number of gc's done as a number representing
the efficiency of memory management.
Mike Hall hallmike at att dot net
http://www.geocities.com/mik3hall
http://sourceforge.net/projects/macnative
