126886 - nsUpdateNotifier.js causes Ts time to go up by ~1%

Status: RESOLVED WONTFIX

(SeaMonkey :: General, defect)

Description

[Chris McAfee]

Forked off from bug 126560, this is the Ts part of that bug.
Samir and I tested this file on mecca, sure enough removing
the file drops Ts by 1% or so, so we are spending some time
doing something here.  Samir to investigate some more.

Comment 1

[Chris McAfee]

Here's the raw data from mecca:

1617 2002:02:20:18:18:36 6612
1618 2002:02:20:18:24:18 6612
1619 2002:02:20:18:30:00 6612
1620 2002:02:20:18:35:42 6611
1621 2002:02:20:18:41:24 6611
1622 2002:02:20:18:47:06 6612
1623 2002:02:20:18:52:48 6612
1624 2002:02:20:18:58:30 6612
1625 2002:02:20:19:08:47 6542
1626 2002:02:20:19:14:29 6542
1627 2002:02:20:19:20:11 6552
1628 2002:02:20:19:28:37 6632
1629 2002:02:20:19:34:19 6614
1630 2002:02:20:19:40:01 6621
1631 2002:02:20:19:45:43 6622

The three 65xx numbers are with the nsUpdateNotifier.js removed,
baseline numbers are before/after that batch of numbers.
I was going to paste the graph here, but it's too jumbled
up to see any changes.

Comment 2

[Samir Gehani]

Dan points out that his alternate delayed app startup notification solution may
be beneficial here if we bypass listening for ``domwindowopened'' + setting a
timer.  Cc'ing Dan.

Comment 3

[Daniel Veditz [:dveditz]]

Let's call it an "idea", not a "solution" -- I have no code to back it up. But
my thinking is that the appstart and profile start notifiers are already
running, already grovelling through the category manager looking for things to
start. If we add some sort of delay syntax to one or both of those, or an
additional delayed-start category, then the only additional work would be the
creating of a timer. The js component would not get parsed and loaded until
later which would seem to beat loading the component and having it put itself to
sleep.

Stupid question here, is update notification the first thing that creates a
timer? Hard to believe so, but maybe loading the timer code itself is the
additional hit.

Comment 4

[Samir Gehani]

My recollection from timer debug output when I added the scriptable interface
was that we are *not* the first timer.

Comment 5

[Peter Trudelle]

nsbeta1+ per Nav triage team, nav3

Comment 6

[Peter Trudelle]

converting nav3->adt3

Comment 7

[Peter Trudelle]

Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.

Comment 8

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 9

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 10

[Vedran Miletic]

retargeting

Comment 11

[Serge Gautherie (:sgautherie)]

This file was removed from 1.9(.0) trunk:
<http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/components/updates/src/nsUpdateNotifier.js&mark=1.13>
{{
1.13	kairo%kairo.at	2008-05-02 10:34	 	cvs remove the xpfe files obsoleted by the recent checkin for bug 383085 which had r=mento, r/sr=Neil via IRC for cvs removal (files are unused now)
}}

R.WontFix on 1.8(.1) branch.