94890 - nsPresShell::ContentAppended spends a lot of time calling GetPrimaryFrameFor

Status: VERIFIED DUPLICATE of bug 77114

(Core :: DOM: Navigation, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

In looking through jprof's of loading large pages, I found that one hotspot was
that we are calling GetPrimaryFrameFor() a lot from within ContentAppended in
order to possibly restore frame positions, etc if this is a Back (or forward I'd
guess).  However, we seem to be doing it even when we're not going back and
forward, and GetPrimaryFrameFor is somewhat expensive to call this much due to
use of IndexOf.  Avoiding calling it except on back/forward would be good, and
finding a way to call it less often when we do need it would be good (on reflows?)

Comment 1

[Radha on family leave (not reading bugmail)]

Eric,  I think this belongs to you. Thanks,

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Duplicate of bug 77114?  And why session history?

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Session history: because of this comment, and the fact that we this appears to
nothing (little?) other than an eventual Restore...()

nsPresShell::ContentAppended(...)
...
 nsCOMPtr<nsILayoutHistoryState> historyState = do_QueryReferent(mHistoryState);
   if (NS_SUCCEEDED(rv) && historyState) {
     // If history state has been set by session history, ask the frame manager 
     // to restore frame state for the frame hierarchy created for the chunk of
     // content that just came in.
     // That is the frames with numbers after aNewIndexInContainer.

This is a dup of 77114.  I'll add some info to that one.

*** This bug has been marked as a duplicate of 77114 ***

Comment 4

[sairuh (rarely reading bugmail)]

mass-verifying Duplicate bugs which haven't changed since 2001.12.31.

set your search string in mail to "CitizenGKar" to filter out these messages.