And here's a comparison of testcase/old-slow-reference-case in latest Nightly (whereas previous comment was using debug build): Profile of loading testcase 5 times: https://share.firefox.dev/4jBsNqT (marker chart shows DocumentLoad durations of 113-160ms) Profile of loading reference case 5 times: https://share.firefox.dev/3GqCz0A (marker chart shows DocumentLoad durations of ~320-350ms) In an opt build, this difference isn't super substantial, and our load time is on par with Chrome as well, so I'm not too worried about this needing further investigation right now. I suspect the primary difference is that we support progressive loading of <embed>-hosted documents, which means we've got various opportunities to yield and allow for style/layout/paint flushes, etc, which happens to slow things down a bit in this somewhat pathological 144-embed-elements scenario, as compared to the testcase which has 144 images which IIRC force the image document to be fully parsed before we allow ourselves to render it.
Bug 1960606 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
And here's a comparison of testcase/old-slow-reference-case **in latest Nightly** which is probably more important for actual performance characteristics (whereas my previous comment was capturing profiles in a debug build): Profile of loading testcase 5 times: https://share.firefox.dev/4jBsNqT (marker chart shows DocumentLoad durations of 113-160ms) Profile of loading reference case 5 times: https://share.firefox.dev/3GqCz0A (marker chart shows DocumentLoad durations of ~320-350ms) In an opt build, this difference isn't super substantial, and our load time is on par with Chrome as well, so I'm not too worried about this needing further investigation right now. I suspect the primary difference is that we support progressive loading of <embed>-hosted documents, which means we've got various opportunities to yield and allow for style/layout/paint flushes, etc, which happens to slow things down a bit in this somewhat pathological 144-embed-elements scenario, as compared to the testcase which has 144 images which IIRC force the image document to be fully parsed before we allow ourselves to render it.
And here's a comparison of testcase/old-slow-reference-case **in latest Nightly** which is probably more important for actual performance characteristics (whereas my previous comment was capturing profiles in a debug build): Profile of loading testcase 5 times: https://share.firefox.dev/4jBsNqT (marker chart shows DocumentLoad durations of 113-160ms) Profile of loading reference case 5 times: https://share.firefox.dev/3GqCz0A (marker chart shows DocumentLoad durations of ~320-350ms) In an opt build, this difference isn't super substantial, and our load time is on par with Chrome as well, so I'm not too worried about this needing further investigation right now. I suspect the primary difference between the fast testcase and slow reference case is that we support progressive loading of <embed>-hosted documents, which means we've got various opportunities to yield and allow for style/layout/paint flushes, etc; and that yielding happens to slow things down a bit in this somewhat pathological 144-embed-elements scenario (particularly in a scenario like android/asan/tsan where everything takes longer and we perhaps yield more times); as compared to the testcase which has 144 images which IIRC force the image document to be fully parsed without any yielding-for-partial-rendering.