Closed Bug 12817 Opened 21 years ago Closed 20 years ago

[feature] XPInstall need to check build num & auto reg flag

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P1)

x86
Other
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cathleennscp, Assigned: dveditz)

References

Details

(Keywords: perf, Whiteboard: [PDT+] 2/15 fix in hand, r=dp)

Blocks: 12361
Target Milestone: M11
Target Milestone: M11 → M12
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine
Summary: [feature] XPInstall need to check build num & auto reg flag → [perf][feature] XPInstall need to check build num & auto reg flag
Target Milestone: M12 → M13
Not a M12 bug, a startup performance improvement.
Blocks: 21564
Blocks: 22176
Target Milestone: M13 → M14
Keywords: perf
Summary: [perf][feature] XPInstall need to check build num & auto reg flag → [feature] XPInstall need to check build num & auto reg flag
cc sfraser & waterson. Simon, do you think this would have enough effect on 
startup performance, especially on the Mac OS (has to traverse dir^h^h^hFolder 
listing), to put it on the beta1 radar?  If so, please add 'beta1' to keyword 
field.
I'm not clear on what the feature is here. dveditz, can you append more detail?
This is the other half of 12361. That one is about getting an XPInstall script 
command that says "register this", and this bug is about turning off AutoReg 
and running it only when flagged by an install. In other words, this one is 
really the performance win, but 12361 is required first or components will 
*never* get registered and we won't be able to install or upgrade any mozilla 
components.
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
*** Bug 11622 has been marked as a duplicate of this bug. ***
Making pdt+ bugs P1
Priority: P3 → P1
From the mailbag...

Warren Harris wrote:
  >
  > Doug,
  >
  > Several more big culprits Chris and I saw tonight was in the area of
  > nsIFile/nsFileSpec. Since both of these are in use, the time is pretty
  > split between them, and they both have the same performance issues:
  >
  > 1. Stat is huge nsNativeComponentLoader::RegisterComponentsInDir calls
  > nsDirEnumerator::HasMoreElements calls nsLocalFile::Exists which
  > accounts for 3% of all execution time. This gets down into
  > MyGetFileAttributesEx on Windows which creates files, closes them etc.
  > Not sure why that's necessary just to enumerate directories.
  >
  > BTW, this is not a run that does the autoregistration. Why are we
  > RegisterComponentsInDir at all?


Suresh Duddi wrote:

  Warren Harris wrote:

  > BTW, this is not a run that does the autoregistration. Why are we
  > RegisterComponentsInDir at all?

  We will go there on every run. xpinstall is relying on it. Dan is working
  on removing that dependency. Once that happens, we can turn off autoreg
  happening at every startup. This is the plan.

dp
Whiteboard: [PDT+] → [PDT+] 2/15
Whiteboard: [PDT+] 2/15 → [PDT+] 2/15 fix in hand, r=dp
Fix checked in
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Build 2000-02-28-09-M15(WIN), 2000-02-28-08-M15(MAC)

Verified on Macintosh and Windows NT/98.  Autoreg flag is getting set from Yes 
to No from Mozilla Registry.  Component.reg increases in size after triggering 
mail.xpi.
Status: RESOLVED → VERIFIED
YEAH!!!!  :-)
No longer blocks: 21564
No longer blocks: 22176
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.