Bug 3906 – some date operations are slow, too slow to enable the Mozilla date test suite

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Geoffrey Garen]

<a href http://bugzilla.opendarwin.org/show_bug.cgi?id=3864>Bug 3864</a> has a patch to enable the 
date tests in the mozilla test suite. Apply it, run the tests, and watch your dual g5 machine magically 
transform into a commodore.

[Carsten Guenther]

I noticed that as well. Date performance is next on my list after Bug 3759 is
fixed. One problem with our date implementation is that a date object only
stores the time (number of milliseconds since 1/1/70 UTC) and calling a getter
or setter for some date component results in a calculation. Mozilla has the same
problem afaik. IE is much faster, I assume they store those components in the
object and only do the calculations when necessary.

[Carsten Guenther]

I will look into that.

[Geoffrey Garen]

The Shark profiler doesn't indicate any particular bottleneck. 

It looks like one major cause of this problem is that the date tests include huge loops - on the order of 
billions of iterations. Consider ecma/Date/15.9.5.10-2.js. The first call to addTestCase causes a loop of 
2,678,400,000 iterations, with a call to TimeInMonth, MonthFromTime, and DateFromTime in each 
loop. These functions are defined in ecma/shell.js, and they don't even use JavaScriptCore's date 
machinery. (They're independent date calculators written totally in JS, used to determine if the result 
returned by JSC is correct.) The only call to JSC's date code is "(new Date(t)).getDate()".

On my machine, the running time of the loop is 39.4 seconds. Still, each function call only takes 39.4s / 
2678400000 iterations / 3 calls per iteration == 0.0000000049s, which is not bad.

On my machine, creating 100,000 Date objects in a loop takes 5.95 seconds. Calling setMinutes
(123456) on each object takes an additional 4.46 seconds.

[Geoffrey Garen]

(In reply to comment #3)

It's not actually 2,678,400,000 iterations; I wasn't considering the stepping size of the loop. The main 
thing that makes the tests too slow to run is that the development build isn't optimized for these loops 
(which, though not in the billions, are still significant).

Our deployment build runs 15.9.5.10-2.js faster than ff, but slower (2x) than ie and opera. 

[Carsten Guenther]

I believe the remaining difference between Safari and IE is due to what I described in comment #1. Once 
bug 3759 is fixed I want to make some changes that should improve performance, basically by keeping 
the tm structure and a field for the milliseconds around instead of recalculating everything from the 
internal value all the time.

[David Kilzer (:ddkilzer)]

I think this may be closed now.  Geoff?

[Cameron Zwarich (cpst)]

We enabled the date test suite long ago, so this bug can be closed.