• littledan's avatar
    [date] Add a cache for timezone names to DateCache · 7e87f446
    littledan authored
    To speed up Date.prototype.toString(), this patch adds a cache in
    the DateCache for the string short name representing the time zone.
    Because time zones in a particular location just have two short names
    (for DST and standard time), and the DateCache already understands
    whether a time is in DST or not, it is possible to keep the result
    of OS::LocalTimezone around and select between the two based on
    whether the time is DST or not.
    
    In local microbenchmarks (calling Date.prototype.toString() in a
    loop), I observed a 6-10% speedup with this patch. In the browser,
    the speedup may be even greater as the system call needs to do
    some extra work to break out of the sandbox. I don't think the
    microbenchmark is extremely unrealistic; in any real program which
    calls Date.prototype.toString() multiple times, the cache should
    hit almost all of the time, as time zone changes are rare.
    
    The proximate motivation for this patch was to enable ICU as a
    backend for timezone information, which is drafted at
    https://codereview.chromium.org/2724373002/
    The ICU implementation of OS::LocalTimezone is even slower than
    the system call one, but this patch makes their performance
    indistinguishable on the microbenchmark.
    
    In the tz database, many timezones actually do have a number of different
    historical names. For example, America/Anchorage went through a number of
    changes, from AST to AHST to YST to AKST. However, both ICU and the
    Linux OS interfaces just report the modern timezone name in tests
    for the appropriate timezone name, even for historical times. I can
    see why this would be:
    - For ICU, CLDR only has two short names in the data file: the one for
      dst and non-dst
    - For Linux, the timezone names do seem to make it into the
      /etc/localtime file. However, glibc assumes there are only two relevant
      names and selects between them, as you can see in its implementation
      of localtime_r:
      http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/time/tzset.c#L573
    So, this cache should be valid until we switch to a more accurate source
    of short timezone names.
    
    BUG=v8:6031
    
    Review-Url: https://codereview.chromium.org/2726253002
    Cr-Commit-Position: refs/heads/master@{#43730}
    7e87f446
date.h 10 KB