On Oct 16, 2007, at 2:46 AM, Eduard de Jong wrote:
BigInteger and all the immutable value classes are intended for
sharing values amongst objects which may live in several threads
and perform actions on the value unknown to the designer of the
value class. The use of BigInteger is one very convenient way to
safely share the result of a computation.
Is one convenient way that I agree is good for a _final_ value.
However, that it is an inefficient way to represent a _interim_ value
for it's normal computational usage still remains at least part of my
premise. I think actual usage should probably take precedence in
design. I have no problem with the end result of a calculation ending
up in a immutable value wrapper. But BigInteger is different from
other Number subclasses like Integer in that it doesn't just wrap a
value, it is used in actual computations more like a primitive.
Integer has no methods for this purpose. Immutable isn't suited to
this usage and is a bad design choice for it.
One good workaround as you pointed out that applied to my example is
to get away from immutable during a local computation where the
interim results are generated. You might always be able to use this
approach and avoid the problems associated with immutable interim
results resulting in a lot of dead memory. Although, since java
doesn't provide a separate mutable class you have to write the to
mutable workarounds yourself.
So, what I'm doing basically has two purposes. Explore a little some
of the alternative optimization algorithms in java that apply to
Elliptic Curve Cryptography and see what they actually seem to do
when performance profiled for both speed and memory. Again I'm hoping
to find Win/Win situations. The second purpose is demonstrate the
idea that BigInteger has design problems that get problematic in
highly iterative computational code to the point that avoiding it's
use in some cases is a good optimization without even any algorithm
changes involved.
I take your point that it is a good general design approach to ensure
safe threading where thread safety is more a concern than
performance. But, getting away from the general, if performance is
more important to your specific case then forcing the code to be
thread safe to the detriment of performance is a bad decision. In
BigInteger's case there doesn't seem to be a lot of awareness of
this. So maybe I am still wrong, my testing is still somewhat
limited. But, so far does suggest that BigInteger as immutable wastes
memory and I'm still assuming, although I'm not claiming to have
proved this, as a side-effect to memory issues it suffers in
performance.
_______________________________________________
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
