601821 - Make Date.getYear and others even faster

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

Bug 578259 made a lot of progress on here by caching the values for hours, minutes, seconds, etc. on the first call. (I note that JSC has the same optimization.) But we still 2x slower on the benchmark given below. This seems to account for a little under half the gap on date-format-xparb, or maybe 3ms on AWFY.

    var date = new Date("1/1/2007 1:11:11");

    var t0 = new Date;
    for (i = 0; i < 400000; ++i) {
        date.getYear();
        date.setTime(date.getTime() + 84266956);
    }
    print(new Date - t0);

Comment 1

[Brendan Eich [:brendan]]

Does the latest patch in bug 584917 help?

/be

Comment 2

[Jan de Mooij [:jandem]]

The problem here is that the test case in comment 0 generates dates with years > 2038. That hits a slow path in the date code. 

I have a fix for this and some other jsdate issues. The patch passes jstests and trace-tests. For the benchmark in comment 0:

- before: 380 ms
- after: 186 ms
- V8: 167 ms

SS improves a bit, but not much; maybe 1-2 ms if we are lucky.

The algorithm is based on V8 and I copied some static int array's from their code. What steps do I need to take to prevent licensing trouble? Do we need to mention them in the jsdate.cpp header?

Comment 3

[Jan de Mooij [:jandem]]

Attachment: WIP

Down to 157 ms with this patch; 10 ms faster than V8. TODO: credit V8 authors; fix style issues, will fix that tomorrow or next week.

Comment 4

[Jan de Mooij [:jandem]]

This helps the micro-benchmark but does not help format-{xparb,tofte} at all. Afaik most of the date functions used by date-format-xparb are cached and quite fast, the biggest problem seems to be string concatenation and "new String(arg)" performance. I will stop working on this for now as there are still more important issues.

Comment 5

[Guilherme Lima]

On Windows 7
Nightly 32.0a1 (2014-05-06) - 747ms
Chrome 34 - 164ms

Comment 6

[Chris Peterson [:cpeterson]]

* Jan: is there any value in landing your WIP patch from 2010? Or should we just close this bug as WONTFIX?

On my MacBook Pro, the test case from comment 0 is just as fast in Firefox and Chrome. Actually, Firefox performance might have regressed since Firefox 29:

* Firefox 29: ~390 ms 
* Beta 30:    ~390 ms
* Aurora 31:  ~440 ms
* Nightly 32: ~450 ms
* Chrome 34:  ~450 ms

Comment 7

[Jan de Mooij [:jandem]]

Chris: I'd say WONTFIX is fine, but the numbers from Guilherme in comment 5 are a bit weird: 747 ms for us, 164 ms in Chrome. That doesn't match your numbers in comment 6 at all.

I'll also test this on Windows, just to make sure there's not a Windows-only issue here.

Comment 8

[Guilherme Lima]

Considering that he probably has a faster machine than I, it seems that it's a Chrome problem on Mac.

Comment 9

[Jan de Mooij [:jandem]]

Closing as WONTFIX; this doesn't seem relevant anymore.