tracker issue : CF-4204880

select a category, or use search below
(searches all categories and all time range)
Title:

Dateformat() performs poorly under load due to internal NumberFormatExceptions

| View in Tracker

Status/Resolution/Reason: To Fix//BugVerified

Reporter/Name(from Bugbase): Bradley W. / ()

Created: 07/23/2019

Components: Performance

Versions: 2018

Failure Type: Performance Issue

Found In Build/Fixed In Build: Final /

Priority/Frequency: Normal / Unknown

Locale/System: / Platforms All

Vote Count: 0

Problem Description:

I'm tuning some client code that runs in a loop many times over as part of a large import.  This line of code looks very simple:

dateFormatVal = DateFormat( DateVal, "mm/dd/yyyy")

The date values were just basic dates in this case such as "01/01/2019"

But is taking up a large amount of processing time.  The FusionReactor profiler shows me this line of code was doing one thing the entire time:

java.lang.Throwable.fillInStackTrace(Native Method)
java.lang.Throwable.fillInStackTrace(Unknown Source)
 - locked <0x46983e2f> (a java.lang.NumberFormatException)
java.lang.Throwable.<init>(Unknown Source)
java.lang.Exception.<init>(Unknown Source)
java.lang.RuntimeException.<init>(Unknown Source)
java.lang.IllegalArgumentException.<init>(Unknown Source)
java.lang.NumberFormatException.<init>(Unknown Source)
sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source)
sun.misc.FloatingDecimal.parseDouble(Unknown Source)
java.lang.Double.parseDouble(Unknown Source)
coldfusion.runtime.CFDouble.parseDouble(CFDouble.java:35)
coldfusion.runtime.Cast._Date(Cast.java:1413)
coldfusion.runtime.Cast._Date(Cast.java:1373)

Using any processing that throws exceptions and then catches them internally is just very bad for performance and eats up tons of CPU too.  It should be possible to detect if a number is a double without using parseDouble().  Now, this import was running that dateFormat() function a very large number of times (millions) but it really shouldn't stick out like a sore thumb so much with extra overhead of dealing with the NumberFormatException over and over again.

Attachments:

Comments: