1371340 - PDF.js shouldn't load anything before opening and painting the first browser window

Status: RESOLVED WORKSFORME

(Firefox :: PDF Viewer, enhancement, P3)

Description

[(no longer active)]

browser/base/content/test/performance/browser_startup.js indicates that the following scripts are loaded before opening the first window:

resource://pdf.js/PdfJs.jsm
resource://pdf.js/PdfjsContentUtils.jsm
resource://pdf.js/PdfStreamConverter.jsm
resource://pdf.js/PdfjsChromeUtils.jsm

Comment 1

[Yury Delendik (:yury)]

It all scripts that provide integration with PDF.js, loading of the viewer is happening at PdfStreamConverter.jsm.

Comment 2

[Yury Delendik (:yury)]

What is the performance cost of loading files above and what is acceptable values? This is the cost of having PDF support and it might not go away with jsplugin/Mortar projects.

Comment 3

[Florian Quèze [:florian]]

(In reply to Yury Delendik (:yury) from comment #2)
> What is the performance cost of loading files above

https://perfht.ml/2rkWDWO shows 96ms in the PdfJs.init(true); call.

> and what is acceptable values?

If something doesn't have an impact on what we'll first paint when opening the first browser window, it shouldn't be running during early startup at all (ie. an acceptable value is 0ms).

I'm saying this because comment 0 says "the following scripts are loaded before opening the first window". But when I run the test locally, I see these modules "loaded before handling user events", which is less of a problem (but could still be improved by using idle dispatch).

For something loaded soon after startup, to not block handling of user events, things that are likely to take longer than 16ms (usually disk I/O) should be done off main thread, or split in smaller chunks.

> This is the cost of having PDF support and it might not go away with
> jsplugin/Mortar projects.

How soon do we need it during startup?

Comment 4

[Yury Delendik (:yury)]

> How soon do we need it during startup?

All PdfJs.init() is connected with wiring up stream converter. Notice that PDF.js code is loaded only when stream converter trying to actually open PDF.

So my guess the time is spend on reading the preferences and other settings databases. Is there any metric when internal PDF Viewer is not select (via Application settings and/or pdfjs.disabled set)? That will show cost of reading the preferences and other settings.

Comment 5

[Florian Quèze [:florian]]

See also bug 1362401.

(In reply to Yury Delendik (:yury) from comment #4)

> So my guess the time is spend on reading the preferences and other settings
> databases.

I gave you a profile showing exactly where the time is spent, so we don't need to guess.

More than half the time is a GetFileVersionInfoSizeW system call doing main thread IO, triggered with this stack:

GetFileVersionInfoSizeW
nsLocalFile::GetVersionInfoField(char const *,nsAString &)
nsOSHelperAppService::GetDefaultAppInfo(nsAString const &,nsAString &,nsIFile * *)
nsOSHelperAppService::GetByExtension(nsString const &,char const *)
nsOSHelperAppService::GetMIMEInfoFromOS(nsACString const &,nsACString const &,bool *)
nsExternalHelperAppService::GetFromTypeAndExtension(nsACString const &,nsACString const &,nsIMIMEInfo * *)
...
isDefaultHandlerApp (resource://pdf.js/PdfjsChromeUtils.jsm)
isDefaultHandler (resource://pdf.js/PdfJs.jsm)
get enabled (resource://pdf.js/PdfJs.jsm)
updateRegistration (resource://pdf.js/PdfJs.jsm)
init (resource://pdf.js/PdfJs.jsm)

Comment 6

[Marco Castelluccio [:marco]]

I believe this has been fixed thanks to bug 1351690 and bug 1479245 and maybe some other bug after those.

Florian, can we close this?

Comment 7

[Florian Quèze [:florian]]

Looking in Windows a startup profile, the first time a PDF.js module is loaded is during the handlersvc-store-initialized observer notification. That's well after first paint, so I would say we can close this.