Re: Bignums, object grind, and garbage collection
John Ersatznom wrote:
"Transparent Object Recycling For example, our benchmark indicates that
adding immutable LargeInteger is up to 8-10x faster than adding
java.math.BigInteger" (Main page. And with semantically-immutable
objects?!)
Be cautious making assumptions about how fast or slow GC makes things.
The GC is fast indeed for multiplicities of small objects with short
lifespans. They are quickly discarded and quickly reclaimed.
It is also tunable, and different algorithms are invokable.
Object creation time may be a tad difficult, but I have read that Java's
creation times are faster than most people believe. I have never heard that
Sun's JVMs re-use objects in some sort of creation pool, but that doesn't mean
that they don't.
The Java lib versions may use O(n^2) algorithms, but a hand-rolled BigFoo with
immutable fields and good algorithms may be faster than you suspect.
Do not overlook the possible influence of JIT compilation to optimize away
apparent inefficiencies in your source, especially under load over time.
Anything involving billions of anything will be slow.
You are probably stuck with having to implement prototypes of more than one
approach, and actually profile and measure them. You could start with the LPGL
libraries nebulous pointed out, compared with Java's standard implementations.
You clearly know your algorithms. The right algorithms will have so much more
effect than putative difficulties with GC or object creation times.
You can also throw hardware at the problem, like multiway / multithreaded
multiprocessors.
- Lew