Bug 118891 – Make PerformanceTests/Layout/line-layout.html 2.6-2.9% faster

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Ryosuke Niwa]

Merge https://chromium.googlesource.com/chromium/blink/+/5d93a708887e75f0157ed95ecdea9dfd1b2b4a09

I was looking at this performance test in pprof or an unrelated reason and
noticed that we were spending 2% of our time clearing a Vector. Rather than
clearing the Vector, we can just set its size to 0 and avoid calling malloc and
free for each iteration of the loop. The Vector is held in a local variable, so
we'll reclaim its storage when the function returns.

[Radar WebKit Bug Importer]

<rdar://problem/14489987>

[Ryosuke Niwa]

Created attachment 207062 [details]
Perf difference (2.65-2.96%)

[Ryosuke Niwa]

This is crazy because m_boxes is always empty (!!!), meaning that our implementation of Vector::clear() performs significantly worse than Vector::reset(0).

[Ryosuke Niwa]

Created attachment 207067 [details]
More diff

Increasing the inline capacity to 64 didn't have any effect as expected.

Apparently this code is insanely hot. Just adding the code in clear() reduces the perf. win to 1.86%:

inline void TrailingObjects::clear()
{
    m_whitespace = 0;
    m_boxes.resize(0);
    if (m_boxes.size() > 200000)
        m_boxes.clear();
}

This is shockingly terrifying.

[Ryosuke Niwa]

I've confirmed that the perf. gain comes from optimizing the text node path. This is frightening.

[Ryosuke Niwa]

Created attachment 207071 [details]
Adding more clear() calls

Adding 3 more (hopefully) no-op clear() calls to the text node path worsens the result by roughly 5%.

[Geoffrey Garen]

I believe this is covered by https://bugs.webkit.org/show_bug.cgi?id=118322.

[Ryosuke Niwa]

*** This bug has been marked as a duplicate of bug 118322 ***