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)

defect

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.
Assignee: bryner → nobody
Product: Firefox → Toolkit
Target Milestone: --- → mozilla2.0
Dave, I suspect this is over optimizing since we have fastload. See bug 311965 comment #7
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.
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.
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
Summary: Investigare refactoring nsExtensionManager.js into startup and runtime components → Investigate refactoring nsExtensionManager.js into startup and runtime components
Blocks: 459117
(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.
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"...)
(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).
Whiteboard: [ts]
Target Milestone: mozilla2.0 → ---
Depends on: 461973
Depends on: 521956
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
Blocks: 461973
No longer depends on: 461973
Whiteboard: [ts] → [ts][blocked on ext manager rewrite]
Priority: -- → P2
Blocks: 447581
No longer blocks: 461973
Depends on: 461973
Whiteboard: [ts][blocked on ext manager rewrite] → [ts]
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.