Closed Bug 3246 Opened 26 years ago Closed 2 years ago

{list} [BLOCK] List numbering code is inefficient

Categories

(Core :: Layout: Block and Inline, defect, P3)

Product:
Core
Component:
Layout: Block and Inline
Platform:
All
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: vidur, Unassigned)

References

Details

(Keywords: hang, perf, testcase)

Since list renumbering happens for any block frame, this is potentially a O(n^2) algorithm. I was looking at this when I hooked up attribute changes for lists and list items. If you make modifications to list renumbering, look at the AttributeChanged method for nsBlockFrame. You will notice that I renumber lists when a list item's "value" attribute is changed. The code currently makes the assumption that the renumbering must be done by the first block ancestor of the list item. If you modify list renumbering to make different assumptions about parenting, please modify this code as well. (test to come)
Summary: List numbering code is inefficient → {perf} List numbering code is inefficient
Priority: P2 → P5
QA Contact: 4110 → 3849
Whiteboard: [Perf]
putting on [Perf] radar
Summary: {perf} List numbering code is inefficient → {perf} {list} List numbering code is inefficient
Blocks: 8691
QA Contact: beppe → petersen
Updating to default Layout Assignee...kipp no longer with us :-(
Why are you re-reassing layout bugs? Do NOT touch layout bugs. The bugs are assigned to Kipp so they can stay neatly organized until we have a new owner for the block/inline code.
Summary: {perf} {list} List numbering code is inefficient → {perf} {list} [BLOCK] List numbering code is inefficient
Keywords: perf
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.
Summary: {perf} {list} [BLOCK] List numbering code is inefficient → {list} [BLOCK] List numbering code is inefficient
Whiteboard: [Perf]
kipp is very unlikely to fix these, since he's not working ont he project any longer. so I'll take a look.
Assignee: kipp → buster
another possibly "future" perf bug. This bug has been marked "future" because we have determined that it is not critical for netscape6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Assignee: buster → waterson
Target Milestone: M17 → Future
Status: NEW → ASSIGNED
putting on the nsbeta1 radar for consideration by engineering
Keywords: nsbeta1
Blocks: 42138
Cc'ing myself. Is this still an issue?
Blocks: 71668
Blocks: 104166
Component: Layout → Layout: Block & Inline
Depends on: 3247
Reassigning ...
Assignee: waterson → core.layout.block-and-inline
Status: ASSIGNED → NEW
Depends on: 288704
Assignee: layout.block-and-inline → nobody
QA Contact: chrispetersen → layout.block-and-inline
The testcase in bug 881090 hangs in nsBlockFrame::RenumberListsInBlock / RenumberListsFor.
Keywords: hang, testcase
Target Milestone: Future → ---
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 12 votes.
:jfkthame, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jfkthame)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(jfkthame)

The testcase mentioned in comment 10 seems to load without any problem now; closing this as WFM.

If there's some other testcase that still exhibits the issue, please file a new bug with details.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.