Lucee 6 "BigDecimal" causes big problems for intensive calculations

language proposals
21

Very true, guys.

Just as verification, I ran my big calculation process (not the simplified example above) and here are the average runtimes, which pretty much verify the answer is correct.

All these runs were done with “smart” whitespace suppression enabled, none had any significant heap use and they all finished successfully:

Lucee 5 no–cfsilent: 16.137 sec avg
Lucee 6 no–cfsilent no–precise: 17.247 sec avg
Lucee 6 no–cfsilent yes-precise: 22.426 sec avg

Lucee 5 with-cfsilent: 4.260 sec avg
Lucee 6 with-cfsilent no–precise: 3.875 sec avg
Lucee 6 with-cfsilent yes-precise: 9.343 sec avg

That’s pretty definitive. Takeaways:

  1. Lucee 5 and 6 perform pretty much identically with whitespace suppression enabled on both.
  2. Even with whitespace suppression turned on, using cfsilent bufferoutput=“false” around the big loop(s) dramatically speeds things up.
  3. Lucee 6 precise math slightly slows things down (as expected) but of course gives big precision advantages.

There you go, hope this info helps someone!

2 Likes
22

Holy cow! I can’t believe it was a white-space issue! Amazing :smiley: :smiley: :smiley: That’s some great detective work everyone!

3 Likes
23

Thanks for that, @gaia-jyh. What a surprising revelation. So, the coast is clear and Lucee 6 may dock, phew.

However, there is still one to-do on the Lucee 6 checklist: ensure that the following results in a double (primitive type), by default, rather than a BigDecimal (reference type).

a = javaCast("double", 1);
b=a-0;
writeOutput("b=" & b & "; Type of b: " & getMetadata(b).getName());
1 Like
24

Speaking of to-dos related to this issue, don’t forget the issue I detailed in this other post, where the STEP attribute of CFLOOP, when it causes non-integer incrementing, does its math using double instead of BigDecimal, which needs to be fixed (at least when Precise Math is turned on in the admin):

25

Even if BigDecimal is slightly slower than double, I will withdraw my earlier reservations. While looking into a separate issue, I came across the blog about the replacement of double by BigDecimal in Lucee 6.

The change is apparently intentional. It is meant to increase arithmetical precision and to simplify coding. In other words, incurring a local disadvantage (slightly lower speed) in favour of a global advantage (simplicity and greater precision). I think it is a praiseworthy change.

1 Like
26

The change is apparently intentional. It is meant to increase arithmetical precision and to simplify coding.

Oh, it was totally intentional, yes, as the blog indicated. It was meant to eliminate the need to use the PrecisionEvaluate function, which is clunky and hard-to-read syntax compared to just using the standard math operators.

I knew that going in, but I incorrectly thought it ate up the heap and caused requests to crash, which turned out not to be the case (see above).

Now that I know it doesn’t actually do that, I like the change too. There are significantly more decimal places of precision now (see above for examples) and no weird things like not being able to represent certain decimal numbers accuately and putting small errors in the results.

Even better, we have a checkbox in the admin to turn it off and use double, for situations where absolute maximum speed is required and high accuracy matters less.

Pretty nice improvement overall!

2 Likes