Just letting you know I've seen this -- I think this is good in theory, but want to provide some specific feedback about the implementation. I'll followup later when I have a chance, hopefully today.

@epriestley, sure. It's not that kind of thing when there's a single solution. Getting more feedback and even thinking of better solution would be really cool.

Just thinking loud, maybe it is to be some more generic routine. In theory if someone adds a huge file differential might also hung up..

Some general thoughts here:

• Generally, on all these diff/browse interfaces we have some issues with:
  • Changesets with a large number of files.
  • Files with a large size and/or large number of text changes.
• The different interfaces handle this to varying degrees. This one does a poor job of it.
• If possible, I don't want to add config for this. I'd rather try to do something reasonable by default, and add config only if we can't get things working well for most users.
• This doesn't guarantee that the problem is fixed:
  • If a file is so large that it takes more than 30 seconds to load the raw data, this won't change the behavior.
  • If a file doesn't have any newlines, this won't change the behavior.
  • Highlighting a file is generally much slower than rendering it. This won't change the behavior for large files which take more than 30 seconds to highlight.
• Users often want to click a button to show the entire file (some of the buttons that exist today are hard to find, and users ask questions about them).

Generally, I think a comprehensive solution should look like this:

1. Time limit the content query (say, to 15s). If it times out, display an error message (like "The file content timed out while loading.").
2. Check the total byte length of the content, and limit it if it's over some limit (say, 4MB).
3. Check the total line length of the content, and limit it if it's over some limit (say, 4K lines).
4. Check the total byte length of the remaining content, and if it's over some limit (say, 1MB), disable syntax highlighting.
5. Render the remaining file content.
6. If we truncated the content in step 2 or 3, add a message ("This file is large (32MB), only the first 4MB are shown. [Show All]").
7. If we disabled highlighting in step 4, add a message ("This file is large (32MB), so syntax highlighting is disabled. [Enable Highlighting]").

I'd like to do this everywhere that we show diffs. We do some of it in some of the places, but it's not very consistent right now.

However, this is a lot of work. Maybe we could implement some pieces of it to solve your problem, and then I could implement the rest later. For example, truncating the file's lines would probably fix the issue you're running into?

Think the proposed solution is indeed comprehensive. And for sure it'll solve our issues and bet will also help keep servers usage sane for those who also does have huge files in their repos.

The change could be done granularly. Meaning now we can implement truncation based on file size/number of lines and do the rest of the things later.

Think i could prepare patch for this within few days. Don't think there's real hurry with this yet and don't want you to spend lots of time on such a specific issue :)