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!

1 Like
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):