Closed Bug 63890 Opened 24 years ago Closed 13 years ago

GetPrimaryFrame could still be faster, and more space efficient


(Core :: Layout, defect, P3)






(Reporter: buster, Unassigned)



(Keywords: helpwanted, perf)

Even after I check in my fix for bug 56432, GetPrimaryFrame() will still need
some work.

1. Part of the reason we scrounge around in the frame tree is because we don't
pre-seed the primary frame map for inline frames or text frames.  This is
because we don't want to unnecessarily bloat the primary frame map in cases
where we never ask for the primary frame (such as caret placement or selection.)
 I think this is too extreme a position.  It would be nice to seed the primary
frame map with the first n inline and text frames, in a classic speed/size
We should examine what it would take to add the code to do this. It's probably a
counter on nsCSSFrameConstructor; a little logic in the 2 places where inline
and text frames explicitly turn off notification to the primary frame map; and
maybe a pref to tell us the cut-off for notification to the primary frame map
for inline and text frames.  That way, the normal desktop browser could default
to some reasonable number (maybe 100?), while memory-constrained systems could
set the bar lower, even to 0 (where we are today.)

2. We need to add a lookup into the undisplay map to skip searches if we already
know the content has no frame.  A lookup in a hashtable map is much, much faster
than walking around in the frame tree, even with the new hint mechanism.
nsCSSFrameConstructor calls SetUndisplayedContent() for every content node that
has display: none.
Today, the undisplay map doesn't quite support what we need to make use of this.
We need to see if we can add a method to make a search for aContent
very fast in the embedded hash table.
This would almost completely remove the lookup penalty for things undisplayed
content like <SCRIPT> and comments in very large documents.

3. the frame manager should be a memory pressure listener, and should clear it's
primary frame map when requested.  the primary frame map is purely a cache, so
we should be able to dump it in low memory situations.
it would be nice to get some data for the ideas I've suggested in this bug, to
see which if any of them should be implemented.

cc-ing some people who might care enough to help get some data, suggest ways
that data could be collected, suggest priorities, etc.
Depends on: 56432
Keywords: helpwanted, perf
Priority: -- → P2
cc'ing relevant drivers and MathML module owner. See above.
comments to Buster's points.
1. yup, mem vs. speed tradeoff. If you wind up w/ this "object cache" it should
be a nsIObserver listening to the MEMORY_PRESSURE topics so it can clear itself
when memory becomes constrained.
2. the indexing idea sounds great, though maybe overkill. How's the tree
searched? I don't know how big the tree is, but maybe we could apply a faster
algorithm there (or is adding the index, basically the faster aglo :-))?
3. :-)
the portion of this that should be moz0.9 is the memory pressure listener (3).
The rest of it is optional, nice to have.  (2) is more important than (1).
Target Milestone: --- → mozilla0.9
making the pres shell a memory pressure listener is easy enough.  Make it an
observer, and add a FlushMemory Call to the frame manager as well. But one trick
is to be sure when you tell the frame manager to dump memory, you should not
delete mPrimaryFrameMap because you need to always have a handle on at least one
frame, the root.  So, you should:
get the primary frame for the root
clear mPrimaryFrameMap
re-insert the root primary frame
*** Bug 70292 has been marked as a duplicate of this bug. ***
i'll put in my vote (and hyatt's) that this doesn't need to be a tree. It should 
just be a hash table.

Just as a side note, GPFF is about 15% of window activation time (brining a 
window to the fg).
Keywords: nsbeta1
pink, re 15% of activation time. Is this because of time spent navigating the 
DST? Or is time spent searching for frames that were never put into the GPFF map 
in the first place?
Moving to mozilla1.0
Target Milestone: mozilla0.9 → mozilla1.0
Interesting. A posting of Troy which shows that he first tried the hashtable 
before moving on to the DST.

      Subject: Checkin (layout) - pres shell
         Date: 16 Jul 99 03:34:37 GMT
         From: (Troy Chevalier)
 Organization: Netscape Communications
           To: raptor-cvs <>
   Newsgroups: netscape.public.mozilla.layout.checkins

I changed the pres shell to use a digital search tree instead of the
hash table for the primary frame map. This should cut down on the amount
of memory that's needed, especially in the case where there are a lot of
entries in the primary frame map.


Troy was no doubt comparing to nsHashtable, which is a malloc pig (see bug
72722).  Sfraser proposed PATRICIA as a more space-efficient d.s. than the DST,
and shaver was going to investigate those vs. raw pldhash.

Blocks: 84820
Not platform specific.
OS: Windows NT → All
Hardware: PC → All
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Blocks: 104166
Target Milestone: mozilla1.0 → mozilla1.1
Reassigning as attinasi won't work on this bug in the next time
Assignee: attinasi → buster
Target Milestone: mozilla1.1alpha → mozilla1.1beta
Buster has not been on the project for over a year. Reassigning back to default 
layout placeholder.
Assignee: buster → attinasi
So... Is GPFF still showing up in profiles?  Are any of the ideas in this bug
still relevant?
Component: Layout → Layout: Misc Code
Priority: P2 → --
Target Milestone: mozilla1.1beta → ---
I think we should just leave this open until the issue is proved one way or the
Priority: -- → P3
Target Milestone: --- → Future
Assignee: attinasi → nobody
QA Contact: chrispetersen → layout.misc-code
This is fixed; nsIContent now has an nsIFrame* member.
Closed: 13 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.