3906 2005-07-08 09:42:07 -0700 some date operations are slow, too slow to enable the Mozilla date test suite 2008-09-03 02:45:03 -0700 1 1 1 Unclassified WebKit JavaScriptCore 412 Mac OS X 10.4 RESOLVED FIXED P2 Normal --- 3759 1 ggaren ggaren ian zwarich oldest_to_newest 14207 0 ggaren 2005-07-08 09:42:07 -0700 <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. 14234 1 carsten 2005-07-08 13:46:36 -0700 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. 14425 2 carsten 2005-07-11 21:55:33 -0700 I will look into that. 15102 3 ggaren 2005-07-23 10:52:00 -0700 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. 15182 4 ggaren 2005-07-25 16:37:48 -0700 (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. 15183 5 carsten 2005-07-25 19:29:52 -0700 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. 71525 6 ddkilzer 2008-02-22 16:03:35 -0800 I think this may be closed now. Geoff? 89995 7 zwarich 2008-09-03 02:45:03 -0700 We enabled the date test suite long ago, so this bug can be closed.