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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Dec 3 14:22:27 PST 2009


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





--- Comment #17 from Janne Koskinen <koshuin at gmail.com>  2009-12-03 14:22:25 PST ---
> Wow, in that case I eat my words. (Yes, I see FTC trace of .Connect(), Close()
> and server API calls almost every day and they are really slow). 
> 
> I will make a phone build using the patch, try it out and report back. 
> 

Slow is relative, we are talking about seconds here :) FTC resolution is
insane, I'm amazed by the tool. .Connect() would be really slow in case where
server is not running and having to start the server process. I would assume TZ
to be always running, could be wrong. Problem is that there really aren't other
alternatives when using pure Symbian APIs. There is one call that could be made
in TLocale but that is said to be deprecated in the header. And for Open C , I
don't have their source code so I can't say what they are doing to spend so
much time on those functions. Best alternative after all would be to fix Open C
and leave datemath.cpp as is.

Try it out and see what numbers you get.

---
Measuring just the context switch doesn't really bare any meaning.. here is
some more interesting numbers for this case. Notice the huge difference, this
is what I was referring to. These numbers haven't been measured with FTC so
they have some extra time from instrumentation.

Nokia E61:
Synchronous IPC function with one argument and result: 143,550000 us / call
(20000 calls in total)
Synchronous IPC function with buffer[32] argument read: 161,900000 us / call
(20000 calls in total)
Nokia E71:
Synchronous IPC function with one argument and result: 7,550000 us / call
(20000 calls in total)
Synchronous IPC function with buffer[32] argument read: 13,250000 us / call
(20000 calls in total)

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



More information about the webkit-unassigned mailing list