On Thu, Jun 3, 2010 at 4:57 PM, Charles Oliver Nutter <[email protected]> wrote:
> Sorry, I meant BigInteger above. Perhaps that changes the situation? > At any rate, I'll reply as though we both said BigInteger. Right, that's what I meant. > Wow, I'd be very surprised if that's true. Big(Integer/Decimal) are > enormous compared to a long, especially on 64-bit JVM, so at a minimum > you have the allocation cost of all that extra data. I actually tested Integers (with autoboxing) against BigIntegers on a 32-bit system (I don't have a 64-bit system at present), and I made sure that the arithmetic operations I was performing never overflowed 32 bits. The additional cost of using BigIntegers was between 2x and 3x, which I assume is the joint cost of: 1) overflow tests that fail; 2) the additional indirection: an Integer contains an int, whereas a BigInteger contains an array with one int. That seems to me small compared to having to handle two integer representations, with special provisions for mixed mode and so on. On Thu, Jun 3, 2010 at 5:16 PM, Per Bothner <[email protected]> wrote: > just seldomly-used (?) caches "Seldom" is always an adverb in English, so "seldom-used" or "rarely-used", take your pick. The latter is probably clearer. > In this case words==null is treated as an optimization of > the case when words.length<=1. > > I think this would be a very worthwhile optimization. I would need some numbers to convince me that removing the indirection would be worth the additional conditional tests, not so much when testing an integer (null checks are cheap) as when creating one. -- GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
