[Webkit-unassigned] [Bug 30681] Symbian port: JS Date operations very slow due to flaky POSIX date/time implementation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30681





--- Comment #14 from Siddharth Mathur <siddharth.mathur at nokia.com>  2009-12-03 10:33:27 PST ---
(In reply to comment #13)
> Created an attachment (id=44235)
 --> (https://bugs.webkit.org/attachment.cgi?id=44235) [details]
> another fix
> 
> Added version that accounts for DST changes. DST is checked from timezone
> server on Symbian.

Janne, 

I am sorry but this is not good performance-wise. As you probably know
client<->server communication in Symbian is a very slow process that requires a
context-switch for each API call. And that's just part of the problem, since
the concerete implementations of Connect(), DoWork(), Close() are time
consuming by themselves [1].  So use of 2 Connect(), 2 Close() , and 2 TZ
server API calls is not acceptable in speed critical code like JSC's Date/time
implementation. Did you get the chance to time this on an N97 using Sunpsider
date tests? 

On a related front, I previously noticed in reading the ECMAscript spec
[Comment #9] that it's flexible about how an implementation does DST isolation.
My understanding is that as long as the (functional) compliance tests pass,
some liberties can be taken. If anyone disagrees, please comment.  

Therefore, another plan of attack _might_ be ..

Patch 1: Remove the use of getUTCOffset() in the c'tor in DateMath.h and also
makes sure that the affected member variable isn't incorrectly used later
on/has invalid data. IIRC, only some ports use that member variable. 

Patch 2: Follow the suggestion in Comment #10 about "one function that returns
a combined (sum) value" of getUTCOffset() + getDSTOffset(). Then it would be
easy to make that wrapper function use either a new flag HAVE_WEAKDSTISOLATION,
or PLATFORM(SYMBIAN), or both to return the value returned by
User::UTCoffset(). 

The advantage of the above approach is that it requires zero Symbian server API
usage and hence will be as efficient as a port's Date code ought to be. The
disadvantage is that the UTC offset is for the current time, not an arbitrary
time in the past or future. But if the ECMAscript functional compliance tests
pass, the latter shouldn't be a problem, IMHO. 

[1] Page 14-19 :
http://www.symbianresources.com/tutorials/advanced/clientserver/Client-ServerFramework.pdf

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.