Closed Bug 480212 Opened 16 years ago Closed 16 years ago

nsUpdateService::_start takes 500ms

Categories

(Toolkit :: Application Update, defect)

ARM
Windows CE
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 311965
Tracking Status
fennec 1.0- ---

People

(Reporter: vlad, Assigned: crowderbt)

References

Details

On CE6, calling _start (in response to profile-after-change) takes 500ms even when there are no updates or anything else pending. It really shouldn't take even 1/10th that long in that case...
Flags: wanted-fennec1.0?
Flags: blocking1.9.2?
Note that this is maybe sorta related to bug 311965, but compiling nsUpdateService.js is quite fast; it's executing _start that takes all the time.
tracking-fennec: --- → ?
tracking-fennec: ? → 1.0a2-wm+
Flags: wanted-fennec1.0? → wanted-fennec1.0+
Assignee: nobody → crowder
Status: NEW → ASSIGNED
Flags: wanted-fennec1.0+
taras: Have you profiled this at all?
(In reply to comment #2) > taras: Have you profiled this at all? yes and after discussions with Mossop we filed 471219, but nobody has taken that up yet. It should save us a fair bit of time.
Depends on: 471219
blocking- per crowder
Flags: blocking1.9.2? → blocking1.9.2-
tracking-fennec: 1.0a2-wm+ → 1.0b1-wm+
tracking-fennec: 1.0b1-wm+ → 1.0-
Flags: wanted-fennec1.0+
Vlad, could you check how long this is taking now? Taras' logs on Maemo show the following changes for nsUpdateService.js. from 7/21 nsUpdateService.js : 109+2+28+36+25 = 200ms from 10/2 nsUpdateService.js : 138+2+6+9+33 = 188ms from 10/8 with patch from Bug 512651 which landed on trunk today nsUpdateService.js : 78+2+7+2+30 = 119 So, it looks like there have been steady improvements and the _start doesn't take hardly any time for me on WinCE though that is without the js_Execute time. Also, I'd like to dupe this over to Bug 311965 for the remaining work unless you'd prefer not to.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.