广泛的重构和迁移通常必须作为一个变化来实现。堆叠式提取请求是将工作拆分为较小更改的绝佳方式，可以更轻松地进行审核，并帮助团队降低出货风险。但是有些变化，比如这个，不能完全拆分。这会给您留下一个可以变得非常大的拉取请求，并且审核对话会导致其增长。
评价体验需要保持快速和流畅，即使差异很大，其对话也很庞大。在GitHub Copilot应用程序中，我们根据该要求重建了拉取请求视图。为了了解这一进展，我们打开了我们可以找到的最大的拉取请求：一个包含2200个文件的开源请求，超过一百万个更改的行和400多个内联评论。以下是我们如何使这个极端的拉取请求性能。
问题的范围以较快的速度呈现较大的差异是众所周知的：虚拟化行，保持安装的DOM较小，并依靠每行都是已知高度的代码行。评论是最难的部分。评论的高度取决于其降价包装方式、可展开部分、其中是否存在回复框以及其图像是否已加载。您可以在渲染时找到所有这些。
这迫使一个不同的架构。三个问题：测量。在渲染之前，您无法知道注释的高度。这打破了让大差异在滚动时保持响应的设计。数据管道。如果供给它的数据管道停止，或者如果它丢弃了已经完成的工作，则快速diff表面毫无价值。我们实际上是如何发现这些漏洞的。
这些问题在特定发动机上的特定滚动位置的负载下出现。因此，我们定义了健康的含义，对表面进行了→测量以回答它，并在无人值守的情况下运行了整个变革措施→改善循环。第1部分：虚拟化，以及注释破坏它的原因第一步是了解使仅代码差异快速的几何结构。一旦注释进入图片，该几何形状就不够了。