While debugging last week, I noticed that when fennec boots into its home screen, it doesn't load the content process in the background. This puts content-process startup on the critical path to load the first web page. We should instead launch the content process in the background after the home screen displays (from onload or something like that ?). This may or may not help with bug 581930.
Add a scriptable method to nsIXULRuntime? Then the front-end can startup the child process whenever is convenient.
Assignee: nobody → doug.turner
Attachment #461581 - Flags: review?
Comment on attachment 461581 [details] [diff] [review] patch v.1 (adding a start method to nsIXULRuntime.idl) (excuse the style on declaring ContentChild)
Attachment #461587 - Flags: review? → review?(jones.chris.g)
Attachment #461605 - Flags: review?(mark.finkle) → review+
Comment on attachment 461610 [details] [diff] [review] patch v.3 (adding a start method to nsIXULRuntime.idl) >diff --git a/xpcom/system/nsIXULRuntime.idl b/xpcom/system/nsIXULRuntime.idl >--- a/xpcom/system/nsIXULRuntime.idl >+++ b/xpcom/system/nsIXULRuntime.idl >@@ -102,9 +102,18 @@ interface nsIXULRuntime : nsISupports > readonly attribute unsigned long processType; > > /** > * Signal the apprunner to invalidate caches on the next restart. > * This will cause components to be autoregistered and all > * fastload data to be re-created. > */ > void invalidateCachesOnRestart(); >+ >+ /** >+ * Starts a child process. This method is intented to pre-start a >+ * child process so that when it is actually needed, it is ready to >+ * go. >+ * >+ * @throw NS_ERROR_NOT_AVAILABLE if not available. >+ */ >+ void startProcess(in unsigned long processType); > }; Nit: please change the name of |startProcess()| to match your comment, to maybe |ensureProcessStarted()|.
Attachment #461610 - Flags: review? → review+
I think this is too generic, can it just be ensureContentProcess() ? This API doesn't make sense for jetpack or plugin processes, which are initialized with specific data and aren't singletons.
(In reply to comment #8) > I think this is too generic, can it just be ensureContentProcess() ? This API > doesn't make sense for jetpack or plugin processes, which are initialized with > specific data and aren't singletons. ensureContentProcess() sounds fine to me
bsmedberg is probably right... make it specific, and change it if we need it to do more.
Comment on attachment 461615 [details] [diff] [review] patch v.4 (adding a start method to nsIXULRuntime.idl) Suits me.
Attachment #461615 - Flags: review?(chris.jones) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I checked in a follow-up bustage fix for non-ipc builds: http://hg.mozilla.org/mozilla-central/rev/39ffc0a802e6
Going to mark this verified as we are top websites seem to be loading fine now. Startup performance is still an issue, but that's tracked elsewhere. Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:2.0b4pre) Gecko/20100820 Namoroka/4.04pre Fennec/2.0a1pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.