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
40 KiB
40 KiB