--- Thomas Singer <email@hidden> wrote:
> Integer, Double and so on all are immutable, so you
> can safely put them in a
> hash map and retrieve them later. If you need
> mutable objects for better
> memory management (you know "don't optimize before
> you really have a
> performance problem"?), you are free to write your
> own classes with the
> methods best suiting your needs.
>
Thanks for the replies. It seems somewhat strange to
me that without more compelling reasons that no
mutable alternatives have been provided. I know that
since 1.3 there are mutable classes that are package
private to BigInteger.
I am currently considering alternative performance
approaches for some crypto code. So it's sort of the
point of the exercise. I have seen, and measured,
where replacing a single BigInteger instantiation with
a constant results in memory improvements.
The code is highly iterative.
In another case, of three choices for a particular
algorithm, the one where I eliminated BigInteger
(extracted the byte[] from a BigInteger and performed
simple manipulations like shift and add, subtract
against that), was both the fastest and used the least
memory. One of the others was a BigInteger version of
the same algorithm, 2nd fastest, worst memory (did
-Xloggc and counted gc's performed).
But, I didn't want to keep up efforts in avoiding
BigInteger only to later have someone say, but we must
have immutable for such and such compelling reason.
The reasons I have heard are good but not completely
compelling, so I guess I'll keep tinkering away to see
if sometimes avoiding it can result in any substantial
performance gains, thanks.
Mike Hall
_______________________________________________
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
This email sent to email@hidden
