1308867 - SDK loader is slowing down content process startup

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect)

Description

[Gabor Krizsanits (INACTIVE)]

Other than bug 1308860 there are more problems. It seems like we load a lot of stuff for devtools and for the SDK which might or might not be possible to optimize.

But there are other weird things to look into, for example in bug Bug 1293684 Bill listed all the script that were loaded with loadSubScript but the SDK modules didn't show up, I want to figure out how exactly are these modules loaded and see if we can do better.

It would be also great if we could do the require part lazily in the child.

Finally, with bug 626814 startup cache is unavailable for the content process, we should figure out how does that affect the loader and if we can do something about it.

Comment 1

[Alexandre Poirot [:ochameau]]

Gabor, feel free to reach me if I can be of any help regarding devtools.

Comment 2

[Gabor Krizsanits (INACTIVE)]

(In reply to Alexandre Poirot [:ochameau] from comment #1)
> Gabor, feel free to reach me if I can be of any help regarding devtools.

Thanks, Alex. I think if you can help with bug 1308332 that would be awesome, I might help out there too with some coding if needed.

Regards of devtools what seem to be THE offender is converter-observer.js. It seems to be pulling in a lot of stuff and it single handedly takes a full second to load on windows in debug mode on my machine. Do you know if all those stuff that it requires is really needed?

It might be less important if we manage to optimize the loader somehow... As a start we could just merge all the minimum required modules into one file at build time, load that at process startup, and add a quick return in require for these modules or something.

Comment 3

[Gabor Krizsanits (INACTIVE)]

Let's dupe this over 1308332. This is the same issue.

Comment 4

[Alexandre Poirot [:ochameau]]

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #2)
> (In reply to Alexandre Poirot [:ochameau] from comment #1)
> > Gabor, feel free to reach me if I can be of any help regarding devtools.
> 
> Thanks, Alex. I think if you can help with bug 1308332 that would be
> awesome, I might help out there too with some coding if needed.
> 
> Regards of devtools what seem to be THE offender is converter-observer.js.
> It seems to be pulling in a lot of stuff and it single handedly takes a full
> second to load on windows in debug mode on my machine. Do you know if all
> those stuff that it requires is really needed?

I already identified this in bug 1302996. There I just disable the jsonview as that's the feature enabling the converter-observer. But I would like to drop the dependency on the "xpcom" module which pulls all the other deps :x

I haven't shared that with devtools group yet, but here is a firefox build without devtools:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-inbound&originalRevision=14fb96dbce5e&newProject=try&newRevision=aef68bb993c9&framework=1
That gives a pretty good insight on how devtools possibly affect firefox.
Do not hesitate to apply:
  https://hg.mozilla.org/try/rev/adf93595b06fd6e690c35d8272d9221f21df3fbb
to see devtools cost regarding the precise codepath you are looking at.
This patch completely strips devtools, so there should be nothing running anymore.
We don't even ship devtools in firefox package.
(Note that's just an experiment)

> It might be less important if we manage to optimize the loader somehow... As
> a start we could just merge all the minimum required modules into one file
> at build time, load that at process startup, and add a quick return in
> require for these modules or something.

That doesn't sound that easy as it requires a build step. But yes, we can surely optimize things there in many different ways.