Closed Bug 160665 Opened 18 years ago Closed 12 years ago

Initial page layout take ages, with very poor interactive response.


(Core :: Web Painting, defect, P3)






(Reporter: adam, Assigned: roc)




(Keywords: perf)

On my 400MHz K6-2 running Linux it takes five minutes of 'nearly hung' time
to lay out the following document:

During this time Mozilla is very unresponsive.  For the first few seconds it's
fairly okay, then subsequently it spends eight-second spans of time ignoring
keyboard/mouse/repaints before catching up and then hanging for another span.

The page data is about 570K and only takes 20 seconds (on my 56.6K modem)
to come down the pipe, but Mozilla still spends another 4m40s doing its
nearly-hung thing.

Once layed-out, interactive response (scrolling etc) is fine.  Window-resize
takes about eight seconds to respond, but that's not intolerable.

This is on CVS-HEAD 2002-08-02
The page consists of thousands of absolutely positioned divs (one per line). 
jprof shows that we spend 52.6% of pageload in
nsViewManager::IsViewInserted(nsView *), which is called from
nsViewManager::SetViewZIndex(), which is mostly called from
nsContainerFrame::SyncFrameViewAfterReflow() but sometimes from

Since none of the items in question actually have a z-index set, it seems like
we should be able to do better here...
Assignee: attinasi → roc+moz
Component: Layout → Views
Keywords: perf
Priority: -- → P3
WFM, SeaMonkey 2005-12-04-01 trunk Linux
WFM also Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Closed: 12 years ago
Resolution: --- → WORKSFORME
Most likely because we no longer create views for abs pos divs, not because the underlying performance problem is fixed (it's not).
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.