Of the other benchmarks, closure-datetime spends about half of its time in DST calculations. And judging from the results of JSC, they do cache DST intensively.
I'll upload a new version of my change later today. It will cache less aggressively, then it does now. On Mon, May 17, 2010 at 11:29, <[email protected]> wrote: > I don't think the date-parse benchmark is a good reason to change the DST > calculation this drastically. It is an artificial benchmark, not used in > published results. The principle of relying on the OS to tell us what is in > DST > and what is not is important, I think, and there are dangers to abandoning > it. > Do other, important benchmarks, also spend most of their time in DST? > > The original problem was to find a way to make V8 notice changes in the time > zone. We can do this on context creation, on a timer, or some other way. > Right > now, I think we do it on missing the DST cache, and also on fetching the > string > for the time zone. > > > > http://codereview.chromium.org/1758013/diff/4001/5003 > File src/platform-posix.cc (right): > > http://codereview.chromium.org/1758013/diff/4001/5003#newcode111 > src/platform-posix.cc:111: time_t tv = static_cast<time_t>(time / > msPerSecond); > Eliminating the floor call changes the answer if time is negative. Are > we not calling this function with negative values? If so, comment. > > http://codereview.chromium.org/1758013/diff/4001/5006 > File src/runtime.cc (right): > > http://codereview.chromium.org/1758013/diff/4001/5006#newcode7280 > src/runtime.cc:7280: static int EquivalentTime(double t) { > This doesn't work. There are also special rules for years divisible by > 1000, and there is the calendar shift to the Gregorian calendar. Also, > Windows now can return different DST values for different equivalent > years in the range 1970 - present, and for compatibility, we report > those different DST values. Only for years outside the range > 1970-2037(?) do we use the equivalent year. > > http://codereview.chromium.org/1758013/show > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
