date-format-xparb spends 12% of TOTAL TIME in localtime_r

• Component: JavaScriptCore
• Status: RESOLVED INVALID

[Eric Seidel (no email)]

date-format-xparb spends 12% of TOTAL TIME in localtime_r

Holy broken date code, batman!

Darin mentioned that he had a rewrite of some of the date code sitting in a patch on his machine at one point in time.  Perhaps that also included a fix for this.

I'm sure there is a simpler (& faster) way to do getDSTOffset()

[Darin Adler]

Created attachment 17060 [details]
here's the old date patch I had lying around -- not sure how good it is

[Eric Seidel (no email)]

Created attachment 17063 [details]
Updated version of darin's date patch (broken, I think)

I think the patch somehow broke (hangs) after updating it to TOT.  I've not investigated yet.

[Eric Seidel (no email)]

Created attachment 17064 [details]
darin's patch, updated for TOT (0.5% slower on SunSpider)

[Eric Seidel (no email)]

localtime_r has made it's way all the way to .6% of *total time*.  KJS::getDSTOffset(double) is 1.1% of total time on my machine.

[Eric Seidel (no email)]

Those numbers are for a --shark20 sample across all tests.

[Alexey Proskuryakov]

Eric, is this bug still valid?

[Eric Seidel (no email)]

Unless someone has re-written the date code, we are likely still spending too much time here, yes.

[Gavin Barraclough]

The date code has been rewritten;  date-format-xparb does not call localtime_r.