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.
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)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
