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.
<rdar://problem/5018674>
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
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.
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.
Comment on attachment 13397 [details] patch to restore time zone caching do we have any quantification on performance improvement?
We need to measure to see if this patch is sufficient. I have a fresh release build so I can try that.
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.
(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?
(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.
Committed revision 19943.