In FreeMarker, we're using BigDecimal by default for all number literals. Also, all arithmetic expressions result in BigDecimal by default. Our reasoning was that people would prefer to be shielded from artifacts of usual number representations -- both integer overflows and floating point fractional representation weirdness.
Nobody's complaining it's slow, but then, FreeMarker is mostly used as a view component in MVC setups, so the normal use cases aren't exactly heavy on numeric computations. All arithmetic as well as number literal creation is actually extracted into an abstract class, ArithmeticEngine, and we ship two of them -- BigDecimalArithmeticEngine (default one) and ConvservativeArithmeticEngine, for people worried about BigDecimal performance. The conservative engine uses boxed equivalents of Java primitive types (so it's presumably faster...). However, it will widen types as necessary instead of overflowing, meaning it'll transparently switch from int to long if you multiply very big ints, and longs to BigIntegers likewise etc. It's called conservative because it tries to preserve the narrower type when doing arithmetic operations unless it is forced to widen. I believe most FreeMarker users don't bother configuring the conservative engine, and thus run with BigDecimal arithmetic. We have some very high traffic website users, and they often send us their profiling results and we improve performance here and there based on their findings. Nobody ever claimed their profiling pointed out BigDecimal arithmetic to be a bottleneck. But as I said, people usually don't write numerically intensive algorithms in FTL (FreeMarker Template Language), so YMMV. Attila. On 2007.12.09., at 9:57, John Cowan wrote: > The language I'm implementing has bignums, and I'm wondering about > how much > it costs to use BigInteger for everything vs. having Integer for > fixnums and BigInteger > for fixnums. I'm already committed to boxing all numbers, so it seems > to me that > I might just as well use BigIntegers all the way down. When invoking > Java methods, > of course, I'll have to cast from BigInteger to Integer (or Long). > > I did a little profiling, which suggested that on the 1.6 JVM the > cost of using > BigIntegers in the Integer range is a small constant factor, 3-4, > presumably > because of the sign-magnitude rather than two's complement > representation. > I've attached the (trivial) program, which uses autoboxing. > > Any thoughts? > > -- > GMail doesn't have rotating .sigs, but you can see mine at > http://www.ccil.org/~cowan/signatures > > > > import java.math.BigInteger; > import java.util.Random; > > class Foo { > > public static void main(String[] argv) { > Random r = new Random(); > int s = Integer.parseInt(argv[0]); > Integer[] small = new Integer[s]; > BigInteger[] big = new BigInteger[s]; > > for (int i = 0; i < s; i++) { > int j = r.nextInt(); > small[i] = j; > big[i] = new BigInteger(Integer.toString(j)); > } > long t1 = System.currentTimeMillis(); > for (int i = 0; i < s; i++) { > for (int j = 0; j < s; j++) { > Integer k = small[i] * small[j]; > } > } > long t2 = System.currentTimeMillis(); > for (int i = 0; i < s; i++) { > for (int j = 0; j < s; j++) { > BigInteger k = big[i].multiply(big[j]); > } > } > long t3 = System.currentTimeMillis(); > System.out.println((t3 - t2) / (t2 - t1)); > } > } --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
