502320 - We spend 3% of the SS runtime in PRMJ_DSTOffset doing syscalls

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Andreas Gal :gal]

Title says it all, really.

Comment 1

[Andreas Gal :gal]

This is mostly date-format-tofte and date-format-xparb.

Comment 2

[Andreas Gal :gal]

Attachment: initial poking at the problem

Comment 3

[Andreas Gal :gal]

Attachment: try being smart about when DST offset shouldn't matter (beats caching)

The attached patch ignores the DST offset, based on some assumptions. Most of them I made while sitting on a plane, so we will have to do some checking and testing for this.

- When getting the year, ignore DST offset if we are not within a day of the year transition. Assuming DST offsets are small, they can't affect the year except for those 2 days. Should be pretty safe.

- When getting the month, ignore DST offset if we are not talking about the first or last (28+) day of the month. Should be pretty safe too.

- When getting the day or weekday, check that we are not near midnight. This assumes that DST offset switching always happens at midnight. It does in every timezone I ever lived in, but we have check for universal truth here.

- Based on the last assumption, we can ignore DST offset for minutes and below.

This cuts down the DST offset calculation significantly.

Potential improvements:

- Cache the DST offset-less local time in the Date object (separately from the full local time). That could save another few cycles.

Currently we win about 20ms.

Comment 4

[Andreas Gal :gal]

So things are a bit more complicated, of course:

We have switching at non-hour boundaries too, and the default switching time is 2am, not midnight.

Rule    Mont    1919    only    -       Mar     31      2:30    1:00    D

The earliest time I have seen in North America is:

Rule    Winn    1945    only    -       Aug     14      23:00u  1:00    P # Peace

The latest:

                        -6:00   -       CST     2001 Apr  1 3:00

Other continents switch even later:

Rule    ChileAQ 1991    1997    -       Oct     Sun>=9  4:00u   1:00    S

And also earlier:

Rule    Russia  1918    only    -       May     31      22:00   2:00    MDST    # Moscow Double Summer Time

And if this is correct, that really screws us over:

Rule    Greece  1979    only    -       Apr      1      9:00    1:00    S

We can still save the day by special-casing the heuristics a bit. I will write a zoneinfo parser to generate the necessary invariants next time I am flying across the Atlantic :)

Comment 5

[Brendan Eich [:brendan]]

dbaron is a time nerd, cc'ing him for advice.

/be

Comment 6

[travis fisher]

How about this for a wild suggestion.  Precompute the start time and end time for DST in each of the years within the operating system trust region (currently 1970-2038*).  This could be done once in js_InitDateClass().  Then DaylightSavingTA() doesn't need to call PRMJ_DSTOffset at all -- it just figures out which year to look at and checks if t >= DST_start[year-1970] || t < DST_end[year-1970].  

Doing the precomputation may be a pain; it might have to be bisection based on calling PRMJ_DSTOffset which is a tad bit expensive in startup time.  But if it was preseeded with a table of guesses as to the right DST times and just has to call the operating system to check if its pre-coded guesses are correct, the normal case (guesses are correct) is something like just 4 calls to PRMJ_DSTOffset for each year being tabulated -- check the guessed start and end dates +- 1 millisecond to see if this is the correct discontinuity points.  Or maybe there is an interface already to find when DST starts and ends in a given year?

* note this code has an explicit year 2038 bug in its working around potential OS year 2038 problems -- it never trusts the OS regarding DST for years 2038 or later, instead asking for DST computations from a similar date back in the 20th century.  But DST rules change periodically at government whim, so the old dates aren't really necessarily equivalent.  

*

Comment 7

[Brian Hackett [Laid off!]]

Attachment: dst offset speedup

This patch speeds up the computation of DST offsets, and modifies the DST cache to handle the pattern seen in date-format-tofte, alternating between two sets of dates several years apart.  Saves 4ms in JM on SS for me.

Comment 8

[Brian Hackett [Laid off!]]

Updated patch at bug 578259.  What's the status of this bug, and how should it interact with bug 578259?

Comment 9

[Brian Hackett [Laid off!]]

Using approach in bug 578259