Bug 12867 – REGRESSION: BenchJS test 7 (dates) is 220% slower than in Safari 2.0.4

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Maciej Stachowiak]

The 24Fun benchmark's flying date test (test 7) is 220% slower in current
WebKit than Safari 2.0.4.

I suspect this was due to adopting Mozilla's date computation code.

[Maciej Stachowiak]

<rdar://problem/5018674>

[David Kilzer (:ddkilzer)]

May be related to Bug 12070 (r18584) or Bug 12057 (r18514) which were follow-on patches to the Mozilla date code.

http://trac.webkit.org/projects/webkit/changeset/18584
http://trac.webkit.org/projects/webkit/changeset/18514

[David Kilzer (:ddkilzer)]

Bug 12070 is the more likely culprit since it removed a caching mechanism.  If this is the cause, we probably need to determine how to cache the timezone value so that the UTC offset is only recomputed when needed.

[Darin Adler]

Created attachment 13397 [details]
patch to restore time zone caching

If the regression is really due to the fact that the time zone isn't cached, then this patch might help. It restores caching of the time zone, using the same "time zone change" notification we have historically used on Mac OS X. It will still be slow on other platforms, though.

[Kevin McCullough]

Comment on attachment 13397 [details]
patch to restore time zone caching

do we have any quantification on performance improvement?

[Maciej Stachowiak]

We need to measure to see if this patch is sufficient. I have a fresh release build so I can try that.

[Maciej Stachowiak]

Safari 2.0.4: 0.149s
TOT w/o patch: 0.479
TOT with patch: .13

It looks like Darin's patch gets us to faster than Safari 2.0.4. However, because JS execution speed has improved so much generally, and we replaced the date code wholesale, I think we should still compare profiles to see if anything leaps out as potentiall speed-upabble before closing this out.

[David Kilzer (:ddkilzer)]

(In reply to comment #7)
> [...] I think we should still compare profiles to see if
> anything leaps out as potentiall speed-upabble before closing this out.

Another potentially "speed-uppable" section of code is that code which calculates the DST offset:  getDSTOffsetSimple() and getDSTOffset().  As I recall it never had any caching mechanism, although that code *appears* to be a hot path since it's called from a lot of places.  (I have not profiled the code to know whether it's a hot path or not.)

Does Mac OS X generate a timezone change when DST takes effect, or is there an equivalent notification for DST changes that may be used?

[Darin Adler]

(In reply to comment #8)
> Does Mac OS X generate a timezone change when DST takes effect, or is there an
> equivalent notification for DST changes that may be used?

I don't think that's a relevant question, because that function doesn't depend on whether DST is in effect at the time it's called. It asks if DST is in effect at a given time that may be in the past or future.

[Darin Adler]

Committed revision 19943.