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.
Thanks Andrew for filing and taking this!
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]
Tobias: can we address this issue while you're in the PDF.js sources?
Yeah, would make sense. Will have a look at it.
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.
You need to log in before you can comment on or make changes to this bug.