Lazily load pdf.js in the content process

NEW
Unassigned

Status

()

Firefox
PDF Viewer
P3
normal
10 months ago
4 months ago

People

(Reporter: mccr8, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

(Reporter)

Description

10 months ago
We load 4 .jsms in the content process at startup for pdf.js, from pdfjschildbootstrap.js. With 4 content processes, that's about 480kb of memory.

There are a few reasons for this:

1. PdfStreamConverter.jsm is loaded so that it can be used as a factory. However, we can avoid loading it until somebody actually creates a factory by moving the classID etc. stuff out of the converter file.

2. PdfContentUtils.init() listens for a message manager message "PDFJS:Child:refreshSettings", and also for the observer notice "quit-application" (the latter just to unregister itself from the mm). This can be avoided by creating a new class to deal with the receiveMessage stuff in the bootstrap file.

3. PdfJs.updateRegistration() checks if pdf.js is enabled. As part of that, it calls PdfjsContentUtils.isDefaultHandlerApp(), which sends a sync message to the parent (which is also not good). I'm guessing that the value of enabled() is the same in the parent and the child, and the bootstrap file is loaded by a loadProcessScript() call, which I assume is in the parent. It should be possible, then, to have two specialized bootstrap files (one for the enabled case, one for the !enabled case) and have the parent check the value and call the appropriate script.

4. In the enabled case, PdfJs.updateRegistration() registers a factory. I think we should be able to move that into the bootstrap file. It does have some state about whether it is registered, but maybe we use the registrar to check if it is registered, as is done in the JSON viewer. In the !enabled case, I think it removes the factory, but I'm guessing that we will never have the factory registered in this case, so we don't need to do anything.

I'll be sure to submit upstream pull requests. I just wanted to have these on file in bugzilla.

Comment 1

10 months ago
Thanks Andrew for filing and taking this!
(Reporter)

Updated

10 months ago
Depends on: 1352218
(Reporter)

Comment 2

10 months ago
I split (3) into bug 1352218.

The rest may be a little messier to fix because the Firefox addon code has to do the same stuff as the bootstrap script and I'd like to avoid too much duplication of code. Maybe I can figure something out.
No longer blocks: 1331674
Whiteboard: [MemShrink] → [MemShrink:P2]

Comment 3

10 months ago
Tobias: can we address this issue while you're in the PDF.js sources?

Updated

10 months ago
Flags: needinfo?(tschneider)
Yeah, would make sense. Will have a look at it.
Flags: needinfo?(tschneider)
(Reporter)

Comment 5

10 months ago
The basic idea here is to move the code that registers observers etc. into the bootstrap script. It may be a little annoying to do because the Firefox addon version of the code also wants to register the same stuff, but I think doesn't use the bootstrap script. I also have some patches in flight to change the bootstrap code a little bit.
(Reporter)

Updated

4 months ago
Assignee: continuation → nobody

Updated

4 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.