Closed
Bug 311968
Opened 19 years ago
Closed 11 years ago
refactor nsExtensionManager.js to load less code at startup
Categories
(Toolkit :: Add-ons Manager, defect, P2)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
INVALID
People
(Reporter: bryner, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf, Whiteboard: [ts])
Compile time for JS components is a good chunk of our startup time. For Extension Manager, we need to do checking on every startup, but we can factor out the code for non-routine situations (extension add/remove, incompatible extensions) and load it lazily.
Reporter | ||
Updated•18 years ago
|
Assignee: bryner → nobody
Assignee | ||
Updated•16 years ago
|
Product: Firefox → Toolkit
Updated•16 years ago
|
Target Milestone: --- → mozilla2.0
Comment 1•16 years ago
|
||
Dave, I suspect this is over optimizing since we have fastload. See bug 311965 comment #7
Comment 2•16 years ago
|
||
Perhaps, I think it could well be worth performing some simple tests to see what sort of improvement we might hit. I think it is also worth investigating for reasons other than perf. Pulled out and used correctly I suspect we could remove the need for the EM restart and extensions.ini. Whether I get time to look at this is another matter, but it's a possibility.
Comment 3•16 years ago
|
||
I agree that a rewrite for other reasons could be worth the time... just that loading less code at startup is most likely not worth it.
Comment 4•16 years ago
|
||
Yeah I probably should have resummarised
Summary: Refactor nsExtensionManager.js to load less code at startup → Investigare refactoring nsExtensionManager.js into startup and runtime components
Updated•16 years ago
|
Summary: Investigare refactoring nsExtensionManager.js into startup and runtime components → Investigate refactoring nsExtensionManager.js into startup and runtime components
Comment 5•16 years ago
|
||
(In reply to comment #3) > I agree that a rewrite for other reasons could be worth the time... just that > loading less code at startup is most likely not worth it. It takes 117ms to load nsExtensionManager in fennec on 810. It's worth refactoring for mobile.
Comment 6•15 years ago
|
||
See https://bugzilla.mozilla.org/show_bug.cgi?id=311965#c10. Downsides to additional XPCOM components and services is increased registration time, increased js -> js xpconnect traversal, and well, more XPCOM. A better approach might be to move code not needed at startup into a js module that's loaded on demand. Hm, could get really trashy and move the code into the js module, and stub the interface impls in the component with memoized getters that load the actual code on-demand from the imported module. (cue "Dueling Banjos"...)
Comment 7•15 years ago
|
||
(In reply to comment #6) > See https://bugzilla.mozilla.org/show_bug.cgi?id=311965#c10. Downsides to > additional XPCOM components and services is increased registration time, > increased js -> js xpconnect traversal, and well, more XPCOM. > > A better approach might be to move code not needed at startup into a js module > that's loaded on demand. > > Hm, could get really trashy and move the code into the js module, and stub the > interface impls in the component with memoized getters that load the actual > code on-demand from the imported module. (cue "Dueling Banjos"...) The WIP I already have for the API rewrite essentially moves all of the extension manager into a code module with a thin XPCOM wrapper so nsAppRunner can talk to it during startup. Does this actually have much effect though? It still needs to load the code module during startup (at least right now anyway).
Updated•15 years ago
|
Whiteboard: [ts]
Updated•15 years ago
|
Target Milestone: mozilla2.0 → ---
Comment 8•15 years ago
|
||
retitling to describe the problem instead of a specific implementation of the fix.
Summary: Investigate refactoring nsExtensionManager.js into startup and runtime components → refactor nsExtensionManager.js to load less code at startup
Updated•15 years ago
|
Updated•15 years ago
|
Whiteboard: [ts] → [ts][blocked on ext manager rewrite]
Updated•15 years ago
|
Priority: -- → P2
Updated•14 years ago
|
Updated•13 years ago
|
Whiteboard: [ts][blocked on ext manager rewrite] → [ts]
Comment 9•11 years ago
|
||
The Add-ons Manager has since undergone a rewrite. Though, bug 746916 was a first pass for doing this to the new Add-ons Manager.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•