Large file diffs in the new 7.x pull request interface have some fairly drastic performance issues. On a high end machine using the latest browsers, scrolling and adding a comment should not result in the tapping out of multiple CPU cores.

In 6.x the file viewer used CodeMirror, which allowed for dynamic rendering of content. By this, I mean that it essentially had the ability to display files of "any" length, because it would only render portions of the file at any given time. This would allow most machines and browsers to handle scrolling and any other event that would be necessary without destroying performance and producing horrible tearing/lagging.

In 7.x the interface was redesigned to simply output every line deemed "relevant" to the diff in the DOM. For small files, this actually seems reasonable. You get to implement some feature requests that have been around for a while (like BSERV-4942), and dramatically simplify the amount of code required to render a diff. However, this interface very quickly breaks down once the lines add up. As more and more elements are added to the DOM, the browsers begin to struggle to keep up (something that your developers have already noted, since there is now a warning message about performance once you reach a fairly low threshold of reviewable lines). 

At my company, we regularly have very large files (some over 30k lines long, and some that are testing files that are even larger than that) that need to be reviewed for changes. With 6.x, these files could be reviewed fully without issue in every browser we use (Safari, Chrome, FireFox). In 7.x, many of these files can't even be viewed due to hard cutoff limits imposed (that you cannot overwrite) and many others just bog down the browser so much that it becomes unusable and not feasible to review the code (a "new" file that is 5,000 lines long, for example, kills performance in Safari so much that typing in a comment produces a lag of about 1 second per character on a top of the line macbook pro). A 5,000 line file is not that large and should be capable of being reviewed without such performance degradation.

My suggestion would be to bring back (or at least implement once a file reaches some line count threshold) the dynamic line rendering so that large files can once again be reviewed.

Attached you'll find an example of a 161,915 line file being rendered in a browser diff tool with no glitching or tearing. This was from a script I wrote to dynamically render just the content in the viewport. Obviously this example is a simple demonstration and there are many more things happening in BitBucket's diff tool, but a diff tool should be capable of handling the things people actually need to diff.