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

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
10 years ago
8 years ago

People

(Reporter: gal, Assigned: gal)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

10 years ago
Title says it all, really.
(Assignee)

Comment 1

10 years ago
This is mostly date-format-tofte and date-format-xparb.
(Assignee)

Updated

10 years ago
Assignee: general → gal
(Assignee)

Comment 2

10 years ago
Created attachment 386847 [details] [diff] [review]
initial poking at the problem
(Assignee)

Comment 3

10 years ago
Created attachment 386889 [details] [diff] [review]
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.
Attachment #386847 - Attachment is obsolete: true
(Assignee)

Comment 4

10 years ago
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 :)
dbaron is a time nerd, cc'ing him for advice.

/be

Comment 6

9 years ago
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.  

*
Created attachment 461302 [details] [diff] [review]
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.
Updated patch at bug 578259.  What's the status of this bug, and how should it interact with bug 578259?
Using approach in bug 578259
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.