Closed
Bug 277984
Opened 20 years ago
Closed 15 years ago
Bad performance laying out table containing ~10000 links
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: 931987, Unassigned)
References
()
Details
(Keywords: perf, testcase)
Attachments
(1 file)
202.56 KB,
text/html
|
Details |
Firefox can't display this site: http://www.gallileus.info/search/history/parts/5467
Comment 1•20 years ago
|
||
What exactly is wrong? Nothing obviously wrong to me on Fx/1.0
Comment 2•20 years ago
|
||
Reproducable freeze (100% CPU) with Mozilla 2005-01-11-07 trunk Linux.
Assignee: firefox → nobody
Severity: normal → critical
Component: General → Layout
Keywords: hang
Product: Firefox → Core
QA Contact: general → layout
Version: 1.0 Branch → Trunk
Comment 3•20 years ago
|
||
Comment 4•20 years ago
|
||
The site does not freeze completely, I was just being impatient - it renders after 30 seconds or so. (2005-01-11-07 trunk Linux.) For the testcase - performance is reasonable if I remove the TABLE container. Changing the links to plain text words also cures the problem. -> Tables
Comment 5•20 years ago
|
||
30 second freeze on WinXP as well Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050114 Firefox/1.0+
Comment 7•20 years ago
|
||
Sounds like the typical "loading a large table is O(N^2) due to the incremental reflows it does" thing.... profile shows nothing obvious but lots of reflow happening.
I guess the usual picture is: 1) we get some chunk from the parser, reflow it and need CPU cycles 2) the parser will deliver a smaller chunk on the next round as the reflow has goten a lot of CPU cycles, we need to reflow the whole table again due to some reflow optimization that cant be used so we eat even more CPU cycles on reflow 3) loop over to 2) and get slower with every round.
Comment 9•20 years ago
|
||
What can be done here in the parser - resp. in what component is tweaking most usefull/efficient?
Comment 10•19 years ago
|
||
Could we some limit on how often reflows are allowed? Like "if page still loading do not reflow if time from last reflow < 1 s".
Comment 11•19 years ago
|
||
*** Bug 268120 has been marked as a duplicate of this bug. ***
Comment 12•19 years ago
|
||
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050714 Firefox/1.0+ The URL loads fine for me
Comment 13•19 years ago
|
||
Reporter, can we mark this WFM?
Reporter | ||
Comment 14•19 years ago
|
||
uff... sure yes. oh man, sorry.
Comment 15•19 years ago
|
||
Thanks for the respone. So, marking WFM.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Comment 16•19 years ago
|
||
I see no difference in performance since I last tested this bug. Using SeaMonkey 2005-10-14-06 on Linux. I see the links up to "189" pretty fast, then I have to wait about 30 seconds (with near 100% CPU) for the rest of the page to render. All other SeaMonkey windows, including Mail, does not respond until the page is fully rendered.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 17•19 years ago
|
||
(In reply to comment #16) > ... I see the links up to "189" pretty fast, This aspect should be fixed. Perhaps a timer or threading issue? > then I have to wait about 30 seconds (with near 100% CPU) for the rest of the > page to render. All other SeaMonkey windows, including Mail, does not respond > until the page is fully rendered. This is true also of IE. In fact IE rendered MUCH slower for me (XP). Mats, is there a reason not to dup to bug 54542 as suggested by Markus?
Comment 18•19 years ago
|
||
Wayne, the difference is that Mats made a profilable testcase, while bug 54542 is trash bin for our performance groupies.
Comment 19•19 years ago
|
||
(In reply to comment #18) > Wayne, the difference is that Mats made a profilable testcase, while bug 54542 > is trash bin for our performance groupies. Still, the testcase is clearly not linux only. And simlar bugs - eg bug 148338, bug 277984. I assume you're in tune with them. Ah, 54542 also pretty dead (now I see the dependencies - most haven't been touched 1-2 years). So if this is kept open, shouldn't this be a blocker to bug 54542?
OS: Linux → All
Comment 20•15 years ago
|
||
the testcase loads in < 2sec so is this bug wfm?
Comment 21•15 years ago
|
||
agree, WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090621 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Status: REOPENED → RESOLVED
Closed: 19 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•