Attached is a partial trace of this situation. It seems that we are *extremely slow* when laying out text with a lot of runs in the renderer. As another example, timings for loading the plaintext version of the King James Bible from Project Gutenberg (4.4MB, 824k words, 100k lines):

Linux 1.5 seconds
macOS 165 seconds (!!)

so Mac text is about two orders of magnitude slower :(

Deleted: harfbuzz-shape.trace.zip 5.5 MB

harfbuzz-shape.trace.zip 5.5 MB Download

+eae, +behdad for "HB slow on Mac" issues

The trace shows >90% of CPU time is spent within blink::CachingWordShaper::Width.

This is due to a combination of two things:

1) AAT text rendering is really slow as we don't have native support for it and fall back on CoreText. Switching to a non-AAT font will likely speed things up by an order of magnitude.

2) 2.5MB of unique words is pretty much the worse case scenario for the current text layout implementation as it relies heavily on caching where each "word" (space separated substrings) are cached. 

LayoutNG performs significantly better for this kind of use case and large-text-file performance is one of the metrics we're tracking.

Can we switch the default font for text/plain to something that is not AAT?

We could but that's a UX decision.