1442478 - Performance cliff loading a Taskcluster log

Status: NEW

(Core :: Layout: Text and Fonts, enhancement, P3)

Description

[Xidorn Quan [:xidorn] UTC+10]

This is basically a copy of bug 1427625.

In that bug, emilio's patch removes unnecessary restyle when the log is loaded incrementally, but it seems loading the log itself takes lots of time in reflow even not loaded incrementally.

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

Attachment: compressed log

This is the compressed log. The best way to test this problem would be extract this log file locally and load it in the browser directly (from a local file).

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

And this is the profile: https://perfht.ml/2CR6Dw0

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

The majority of the time is spent in reflowing text, which is actually expected. I'm not sure whether there is anything actionable from this, though.

Comment 4

[Jonathan Kew [:jfkthame]]

We spend a lot of time on text shaping, which is unfortunate given that this is (at least virtually all) plain ASCII text being rendered in a monospaced font. But of course we don't *know* ahead of time that it's all going to end up monospaced; there could be stray non-Latin characters in there somewhere, or whatever...

Log files like this also fail to benefit much from the shaped-word cache, because there are lots of strings (e.g. long paths) that are too long for the word cache; so we see lots of time under gfxFont::ShapeFragmentWithoutWordCache. And even among the short strings, which do go into the word cache, there are an unusually large number of unique "words" such as high-precision timestamps that won't end up benefiting much from cache hits.

Not saying there's nothing to do here, but it may not be easy to identify opportunities for short-cuts or fast paths. Note also that even "simple" monospaced fonts like Courier New do include OpenType layout tables. Maybe we could analyze these and figure out that no features will in fact be applied to a run of Latin-only text, for example, and so we could bypass hb_shape and take a fast path for textrun construction. Potentially quite a bit of complexity to try and improve performance for a relatively rare case, though; it wouldn't have any benefit for "normal" web content.

A bigger win, probably, would be at a higher level, if we could identify places where we're actually doing redundant reflows.

Comment 5

[Jonathan Kew [:jfkthame]]

In particular, I think we must be reflowing the content repeatedly as it gets loaded -- and because it's a plain text file, we keep appending text to the same element, which then needs to be reflowed, rather than adding new elements as we'd usually do with more typical HTML pages.

Once the whole file is loaded, the performance of zooming in or out (which of course requires all the text to be reflowed) is vastly better than the initial loading. I assume this is because we just reflow the whole thing, but don't keep reflowing the gradually-growing content as each chunk of it arrives from the file being loaded.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

When loading from local file, it shouldn't be reflowed multiple times. According to the profile, we are probably reflowing it twice, because there is a nsHtml5TreeOperation::AppendText in the middle of the process.

Also you can see bug 1427625 comment 4 for a profile that do gradually growing, and it seems our incremental reflow actually works in that case, that each time when a small amount (relative to this huge file) is appended, the reflow doesn't take this long.