Bugzilla

My " The question then is, what push made us go from serializing 5 vs. 12 copies of the favicon, in the regression pushlog?"

Hmm, though even in the "good" 2018-10-05 build, if I hold down ctrl+PageDown to view every tab, my `recovery.jsonlz4` "only" increases to 39MB with 21 copies of the data URI -- not 500 copies -- and the periodic idle-reserialize time doesn't change, somehow.  In my "bad", build, I wasn't able to get a `recovery.jsonlz4` file yet; Firefox may have crashed at shutdown while regenerating it, I think (?)

Here are profiles of the good/bad builds with that setup (all of the 500 tabs having been viewed)
"good" 2018-10-05: https://share.firefox.dev/481K8U1  (1s per serialization)
"bad" 2018-10-06: https://share.firefox.dev/3Rojzmx  (7s per serialization)

They look roughly the same as in comment 35.

Also: If I run the "good" build with an explicit process-count of 8 set up-front in `prefs.js` (and confirm 8 content processes shown in a profile), that doesn't seem to change its metrics; its serialize operation is still ~1s.

So comment 38 and the process-how-many-tabs-have-you-viewed metric may not actually be relevant, sorry.

(In reply to Jens Stutte [:jstutte] from comment #39)
> In any case what you describe sounds like deduplicating the favicons could reduce the data significantly here (maybe even in memory before serializing anything) ?

That's very likely true, yeah. That's bug 1867137.

Possible correction to my theorizing on "what made us go from serializing 5 vs. 12 copies of the favicon, in the regression pushlog?"

Even in the "good" 2018-10-05 build, if I hold down ctrl+PageDown to view every tab, my `recovery.jsonlz4` "only" increases to 39MB with 21 copies of the data URI -- not 500 copies -- and the periodic idle-reserialize time doesn't change, somehow.  In my "bad", build, I wasn't able to get a `recovery.jsonlz4` file yet; Firefox may have crashed at shutdown while regenerating it, I think (?)

Here are profiles of the good/bad builds with that setup (all of the 500 tabs having been viewed)
"good" 2018-10-05: https://share.firefox.dev/481K8U1  (1s per serialization)
"bad" 2018-10-06: https://share.firefox.dev/3Rojzmx  (7s per serialization)

They look roughly the same as in comment 35.

Also: If I run the "good" build with an explicit process-count of 8 set up-front in `prefs.js` (and confirm 8 content processes shown in a profile), that doesn't seem to change its metrics; its serialize operation is still ~1s.

So comment 38 and the process-how-many-tabs-have-you-viewed metric may not actually be relevant, sorry.

(In reply to Jens Stutte [:jstutte] from comment #39)
> In any case what you describe sounds like deduplicating the favicons could reduce the data significantly here (maybe even in memory before serializing anything) ?

That's very likely true, yeah. That's bug 1867137.

Possible correction to my theorizing on "what made us go from serializing 5 vs. 12 copies of the favicon, in the regression pushlog?"

Even in the "good" 2018-10-05 build, if I hold down ctrl+PageDown to view every tab, my `recovery.jsonlz4` "only" increases to 39MB with 21 copies of the data URI -- not 500 copies -- and the periodic idle-reserialize time doesn't change, somehow.  In my "bad", build, I wasn't able to get a `recovery.jsonlz4` file yet; Firefox may have crashed at shutdown while regenerating it, I think (?)

Here are profiles of the good/bad builds with that setup (all of the 500 tabs having been viewed)
"good" 2018-10-05: https://share.firefox.dev/481K8U1  (1s per serialization)
"bad" 2018-10-06: https://share.firefox.dev/3Rojzmx  (7s per serialization)

The durations look roughly the same as in comment 35 (where I hadn't viewed every tab).  So have-all-the-tabs-been-foregrounded doesn't seem to be a relevant difference after all.

Also: If I run the "good" build with an explicit process-count of 8 set up-front in `prefs.js` (and confirm 8 content processes shown in a profile), that doesn't seem to change its metrics; its serialize operation is still ~1s.

So comment 38 and the process-how-many-tabs-have-you-viewed metric may not actually be relevant, sorry.

(In reply to Jens Stutte [:jstutte] from comment #39)
> In any case what you describe sounds like deduplicating the favicons could reduce the data significantly here (maybe even in memory before serializing anything) ?

That's very likely true, yeah. That's bug 1867137.

Possible correction to my theorizing on "what made us go from serializing 5 vs. 12 copies of the favicon, in the regression pushlog?"

Even in the "good" 2018-10-05 build, if I hold down ctrl+PageDown to view every tab, my `recovery.jsonlz4` "only" increases to 39MB with 21 copies of the data URI -- not 500 copies -- and the periodic idle-reserialize time doesn't change, somehow.  In my "bad", build, I wasn't able to get a `recovery.jsonlz4` file yet; Firefox may have crashed at shutdown while regenerating it, I think (?)

Here are profiles of the good/bad builds with that setup (all of the 500 tabs having been viewed)
"good" 2018-10-05: https://share.firefox.dev/481K8U1  (1s per serialization)
"bad" 2018-10-06: https://share.firefox.dev/3Rojzmx  (7s per serialization)

The durations look roughly the same as in comment 35 (where I hadn't viewed every tab).  So how-many-tabs-have-been-viewed doesn't seem to be a relevant difference after all.

Also: If I run the "good" build with an explicit process-count of 8 set up-front in `prefs.js` (and confirm 8 content processes shown in a profile), that doesn't seem to change its metrics; its serialize operation is still ~1s.

So comment 38 and the process-how-many-tabs-have-you-viewed metric may not actually be relevant, sorry.

(In reply to Jens Stutte [:jstutte] from comment #39)
> In any case what you describe sounds like deduplicating the favicons could reduce the data significantly here (maybe even in memory before serializing anything) ?

That's very likely true, yeah. That's bug 1867137.

Possible correction to my theorizing on "what made us go from serializing 5 vs. 12 copies of the favicon, in the regression pushlog?"

Even in the "good" 2018-10-05 build, if I hold down ctrl+PageDown to view every tab, my `recovery.jsonlz4` "only" increases to 39MB with 21 copies of the data URI -- not 500 copies -- and the periodic idle-reserialize time doesn't change, somehow.  In my "bad", build, I wasn't able to get a `recovery.jsonlz4` file yet; Firefox may have crashed at shutdown while regenerating it, I think (?)

Here are profiles of the good/bad builds with that setup (all of the 500 tabs having been viewed)
"good" 2018-10-05: https://share.firefox.dev/481K8U1  (1s per serialization)
"bad" 2018-10-06: https://share.firefox.dev/3Rojzmx  (7s per serialization)

The durations look roughly the same as in comment 35 (where I hadn't viewed every tab).  So how-many-tabs-have-been-viewed-or-loaded-via-some-processCount-based-minimum doesn't seem to be a relevant difference after all.

Also: If I run the "good" build with an explicit processCount of 8 set up-front in `prefs.js` (and confirm 8 content processes shown in a profile), that doesn't seem to change its metrics; its serialize operation is still ~1s.

So comment 38 and the process-how-many-tabs-have-you-viewed metric may not actually be relevant, sorry.

(In reply to Jens Stutte [:jstutte] from comment #39)
> In any case what you describe sounds like deduplicating the favicons could reduce the data significantly here (maybe even in memory before serializing anything) ?

That's very likely true, yeah. That's bug 1867137.