page load dominated by nsVoidArray::InsertElementAt()

VERIFIED FIXED in M18

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Chris Waterson, Assigned: Chris Waterson)

Tracking

({perf})

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Assignee)

Description

18 years ago
On our profiling sojourn, pav and I discovered that the above HTML directory 
listing spent about 25% of its time nsVoidArray::InsertElementAt(). The time is 
split about 65/20/15 between memcpy(), ::operator new(), and ::operator 
delete().

It turns out that the <pre> tag ends up with about 30,000 elements, and we grow 
the array only 8 elements at a time. Zoiks!

We changed the void array to grow exponentially, and were able to get rid of 
this. Since we only managed to get a partial profile (and this case is somewhat 
degenerate), I'm wondering if anyone has seen this problem in long text 
documents? If so, seems like a no brainer to make nsVoidArray::InsertElementAt 
a bit smarter...
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: perf
Target Milestone: M14

Comment 1

18 years ago
Pages with lots of PRE loading slowly is a known problem. No one in layout has 
spent that much time looking into it yet, but your analysis sounds correct.

It seems we spend a lot of time with different people all looking at the void 
array code and concluding the growth algorithm isn't well suited for their 
particular needs. Maybe we should make it more configurable so that the clients 
can control it directly rather than change the generic growth algorithm in which 
case we're bound to make someone unhappy or use too much space (i.e., have it be 
too sparse)
(Assignee)

Updated

18 years ago
Target Milestone: M14 → M16
(Assignee)

Updated

18 years ago
Target Milestone: M16 → M18
(Assignee)

Comment 2

18 years ago
Although this isn't *really* a dup of 19051, and should be maintained as a test 
case that we profile, getting rid of nsTextRun will make a big difference. We 
should re-evaluate once that fix is in.
Depends on: 19051
(Assignee)

Comment 3

18 years ago
1. nsVoidArray was changed to grow exponentially
2. nsTextRun was nuked yesterday.

Marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 4

18 years ago
Marking verified per last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.