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...

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.

1. nsVoidArray was changed to grow exponentially 2. nsTextRun was nuked yesterday. Marking fixed.

Marking verified per last comments.