On Rendering Diffs
7 points by jado
7 points by jado
Eternally frustrating that Microsoft seems incapable of allocating performance engineers to work on The Most Important Part of GitHub (the code view). I’m not sure what happened to the main pierre.co site, looks like they shut it down, but I hope this tech can be integrated into a larger code hosting platform.
It's mind boggling that Github hides "large" diffs. This is dangerous as it makes it easier to sneak in unseen code changes in PRs. Github's threshold for a "large" diff change isn't even large. Browsers can easily render static HTML 10× larger than that.
It's ironic that Microsoft so heavily invested in GenAI that made the problem much worse and is killing Github.
I would love to see a performance comparison with terminal-based reviewing tools like revdiff. I'm not necessarily expecting that pierre's diff will be slower, but it sure seems to take a lot of effort to get where they are today.
https://diffshub.com/torvalds/linux/compare/v6.0...v7.0
Loading this, I can't help but wonder why it streams the diff the way it does. It seems to go depth-first, i.e. top-level folders are not loading for a long time until all the children have been processed. I'd have liked top level folders to load instantly, but collapsed.
Is the actual diffing happening on github and they just load a huge patchfile?