Skip to content

V
V8
Switch branch/tag
  1. 18 Oct, 2017 1 commit
  3. 13 Oct, 2017 1 commit
  5. 21 Sep, 2017 1 commit
  7. 22 May, 2017 1 commit
  9. 24 Apr, 2017 1 commit
  11. 11 Apr, 2017 3 commits
  13. 11 Mar, 2017 1 commit
    • 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
  15. 03 Mar, 2017 1 commit
    • littledan's avatar
      [date] Refactor TimezoneCache to be separate from the OS · ccfe50b9
      littledan authored 
      This refactoring is preparatory work to enable ICU to be the backend
for timezone information rather than system calls. In the process, a
bit of code duplication that was inserted in the Solaris port patch is
eliminated here among modern POSIX backends.

One possible performance downside of this patch is that it introduces
a virtual method call for operations which were previously not virtual
methods. However, a couple factors mitigate this effect:
- The DateCache minimizes the need for calls into the TimezoneCache
- These calls were already not very high performance, as they included
  a system call which requires an RPC to get out of the sandbox, and
  they are surrounded by C++ builtins, which require a JS to C++
  transition.
- A future transition to ICU, enabled by this refactoring, may improve
  performance by eliminating the system call.

BUG=v8:6031

Review-Url: https://codereview.chromium.org/2731463003
Cr-Commit-Position: refs/heads/master@{#43588}
      ccfe50b9
  17. 07 Oct, 2016 3 commits
  19. 07 Jan, 2016 1 commit
  21. 05 Jan, 2016 1 commit
    • bmeurer's avatar
      [runtime] Migrate several Date builtins to C++. · 065e9c53
      bmeurer authored 
      Almost all of the Date builtins always call into C++ at least once
anyway, so parsing, compiling and executing the JavaScript wrappers
is just a waste of time.  The most important part here is the Date
constructor itself, which is one of the blockers for new.target in
TurboFan, because compiling the Date constructor takes too much time
with TurboFan (for no reason since we end up in C++ anway).

R=cbruni@chromium.org

Review URL: https://codereview.chromium.org/1556333002

Cr-Commit-Position: refs/heads/master@{#33109}
      065e9c53
  23. 20 Aug, 2015 1 commit
  25. 01 Jun, 2015 1 commit
  27. 13 Jan, 2015 1 commit
  29. 04 Aug, 2014 1 commit
  31. 30 Jun, 2014 1 commit
  33. 03 Jun, 2014 1 commit
  35. 29 Apr, 2014 1 commit
  37. 28 Mar, 2014 1 commit
  39. 14 Mar, 2014 1 commit
  41. 11 Mar, 2014 1 commit
  43. 06 Dec, 2013 1 commit
  45. 09 Mar, 2012 1 commit