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...
Status: NEW → ASSIGNED
Target Milestone: M14
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)
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
1. nsVoidArray was changed to grow exponentially 2. nsTextRun was nuked yesterday. Marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.