Disable syntax coloring for large files to address rendering performance problems

This is a request to allow a configurable limit to be set on files reviewed using Crucible, such that when these limits are exceeded, the syntax coloring will be automatically disabled, and a warning might be included at the top that specifies that due to the very large file content, syntax coloring has been disabled to improve performance.

Crucible performance when browsing reviews that include changes to large files can be very slow. For changes to files with 30,000 lines of C/C++ code with "10 lines of context" it can take 5 seconds or more with a fast web browser, and with "full context" it can take 30 seconds (real measurements performed today for a file in a sample review today). Using Chrome reduced the time to 25 seconds, but this is still a very long time for users to wait in order to see a response to their page clicks. Using Chrome did reduce the time to 25 seconds, but this is still very long.

In analysis we have done, I believe a majority of the time is spent in the web browser parsing and generating the DOM, and then rendering the DOM to the page. In the existing tool that the users are using, it does not do syntax coloring. Taking a look at the DOM, I see that the Crucible DOM is very rich, with all keyword, identifiers, and other such symbols configured with varying CSS classes. For 30,000 lines of rich text, it can take a lot of processing to lay out the page. For some of our users, Firefox will give timeout warnings, and for others of our users, the browser might crash and seem to never come back. The users blame Crucible, because their existing tool that supports these files just fine apparently.

In Bitbucket, which we also use, I see that Atlassian has implemented a number of alternate behaviours when certain configurable limits are reached, in order to maintain the health of the instance. The service can be degraded while still allowing it to provide significant value. In Crucible, I have also noticed improvements to dashboards and such where if a particular query takes too long to complete, it will return early results and warn the user that the query did not complete in time, and that control is being returned to the user early rather than continuing to wait for the full results.

I would like a site-wide configurable limit to be set on files reviewed using Crucible, such that when these limits are exceeded, the syntax coloring will be automatically disabled, and a warning might be included at the top that specifies that due to the very large file content, syntax coloring has been disabled to improve performance.

For example, the limit might be "# of lines in a source file", and it might default to 5,000 lines. If the number of lines is less than the limit, than the file would be rendered with full syntax colored enabled. If the number of lines is greater than the limit, the file would be rendered as simple lines of text without any special syntax coloring enabled, and a warning at the top would explain to the user why this has happened.

Please put aside judgement around why files are 30,000 lines long. The fact is, we have software projects that include files such as these, that do get changed, and we need to be able to effectively review them in a code review tool, often with full context. In these cases, I would prefer a careful degrading of the feature set to something that might have acceptable performance, rather than having Crucible seem to fail, and having users refuse to use Crucible because their other tool works fine with 30,000 line files and Crucible does not.