eg http://archive.mozilla.org/pub/b2g/nightly/2015/11/2015-11-26-03-02-09-mozilla-central/b2g_mozilla-central_flame-kk_nightly-bm72-build1-build76.txt.gz Profile: http://people.mozilla.org/~bgirard/cleopatra/#report=a81c4b4db82965b8efbc58ded8282d5e7f0b98fb (today's Mac nightly) Discussion with roc and karlt: <nthomas> When I load a build log like http://archive.mozilla.org/pub/b2g/nightly/2015/11/2015-11-26-03-02-09-mozilla-central/b2g_mozilla-central_flame-kk_nightly-bm72-build1-build76.txt.gz it hangs firefox for a few seconds. Has done this for ages, and vaguely recall it's from careful rendering of the text. Is there any way to get onto a fastpath if you've got, say, <nthomas> a text/plain document that you're going to display with a relatively simple (I assume!) font like courier. ie no ligatures or fancy kerning to deal with <nthomas> there's also some gzip decompression to do on that <nthomas> spending a lot of time reflowing, maybe http://people.mozilla.org/~bgirard/cleopatra/#report=5d135745f7250b74ccaa1bd7b80f1064de7bcde1 <roc> many system monospace fonts do have ligatures <roc> but yeah, there's probably more stuff we can do there <nthomas> presumably 23MB of text is not that common on the web, so it's a case we optimize for ? <roc> we do have some optimizations for it <roc> that profile claims to be for a b2g build? <nthomas> it's a b2g build log, loaded on osx <roc> doesn't seem to have symbols <nthomas> that's strange, it's just 43.0b6 <nthomas> can redo on nightly if you like <nthomas> http://people.mozilla.org/~bgirard/cleopatra/#report=a81c4b4db82965b8efbc58ded8282d5e7f0b98fb (yep, I saw roc dropped form IRC) <karlt> nthomas: yes, http://people.mozilla.org/~bgirard/cleopatra/#report=a81c4b4db82965b8efbc58ded8282d5e7f0b98fb seems to indicate reflow of lines and text with quite a chunk in shaping <karlt> we used to blame slow logs on bidi years ago; i don't recall that bug being fixed, but i don't know whether it is involved here or not <karlt> i don't know how to distinguish between slow text layout and callers doing too much <karlt> the process of loading the page part by part and reflowing at each stage is susceptible to an O(n^2) problem; i don't know what is done to avoid that <nthomas> fwiw, safari isn't better. I appears to be because it renders progressively, but as soon as you search for something if gets very laggy <roc> oh, this text has tabs in it? <karlt> evil text? <nthomas> 2357, apparently <nthomas> in 2336 lines, out of 108k lines/29M characters total <roc> 30% of the profile is in ShapeFragmentWithoutWordCache <roc> that suggests the text contains a lot of "words" of over 32 characters without intervening spaces <nthomas> sounds a lot like paths <roc> mmm yeah <roc> looks like we're using core text for shaping <roc> results might be a bit different with an OpenType font <roc> you could file a bug and CC jfkthame and jdaggett to see if they have any ideas roc wonders whether we really need to flush layout in nsDocumentViewer::LoadComplete

This is fairly easy to track down with text performance logging: NSPR_LOG_MODULES=textperf:5 NSPR_LOG_FILE=/path/to/textperf.log ./firefox-bin -P myprofile For the logfile case, you get something like this (running with latest nightly): (textperf-reflow) 0x12d0e5000 time-ms: 8241 reflow: 1 chars: 29530820 content-textruns: 1 chrome-textruns: 0 max-textrun-len: 29530820 word-cache-lookups: 1102203 word-cache-hit-ratio: 0.967 word-cache-space: 0 word-cache-long: 227277 pref-fallbacks: 0 system-fallbacks: 0 textruns-const: 1 textruns-destr: 0 generic-lookups: 2 cumulative-textruns-destr: 0 (textperf-loaddone) 0x12d0e5000 time-ms: 8653 reflow: 3 chars: 29530820 [http://archive.mozilla.org/pub/b2g/nightly/2015/11/2015-11-26-03-02-09-mozilla-central/b2g_mozilla-central_flame-kk_nightly-bm72-build1-build76.txt.gz] content-textruns: 1 chrome-textruns: 0 max-textrun-len: 29530820 word-cache-lookups: 1102203 word-cache-hit-ratio: 0.967 word-cache-space: 0 word-cache-long: 227277 pref-fallbacks: 0 system-fallbacks: 0 textruns-const: 1 textruns-destr: 0 generic-lookups: 2 cumulative-textruns-destr: 0 Note the max-textrun-len value, we're jamming 29MB into a single textrun and shaping it. This is true for all plain text files and pre element contents, they are shaped as a single long string. This results in a single 8.4 second reflow which is why the user sees a hang happening. We need to break up large elements like this (bug 934770) and interrupt long reflows better (bug 962412). Our text shaping is not hugely inefficient compared to other browsers, if you query offsetHeight of large text elements in those browsers it takes a while also. However, because they are more efficiently chunking the work, the user-perceived performance *and* responsiveness is far better.