Computing the syntax highlighting for diffs of very long files can be
slow -- even when the delta is small and the context is not set to
"whole file". This is partly because, by the nature of parsing, the
computation must start at the beginning of the file, even if the visible
delta is in the middle or at the end. Currently, the computation also
continues to the end of the file, regardless of whether that content is
visible.
This slowness can be problematic when rendering diffs inline, because
inline diffs are rendered in order, and the n'th diff will not begin
rendering until the n-1'th diff has finished computing syntax
highlighting. This cause can be hidden from users, because the work that
the browser is doing is often never displayed.
This situation is similar to the safety-bypass mechanism that helps
users avoid very slow renders on large files when they have enabled
"whole file" context.
The diff builder already houses logic to avoid computing syntax
highlighting when the diff contains any very long line. This was added
to avoid needless highlighting of machine-generated / minified files.
With this change, the diff builder takes the diff length into account,
in addition to individual line length.
The notion of the overall diff length is borrowed from the safety
bypass. Because a diff represents two files, it can describe two
different file lengths. The length computation used in the safety bypass
approximates the number of vertical lines that would appear in a
side-by-side diff, and it's appropriate here because it's again being
used to approximate the computational effort of processing a diff.
Change-Id: I1d24846e550eb631bc791267630ae1ed511b6f75
7e9b0c382f