VSCode C扩展中Razor文件加载性能问题分析与优化

在最新版本的VSCode C#扩展中，开发者报告了一个关于Razor文件加载时CPU使用率持续偏高的问题。经过深入分析，我们发现这是由于Razor语言服务器在处理虚拟C#文件时触发了过多的LSP didOpen/didClose事件，导致其他语言服务器请求被阻塞。

问题现象

当开发者加载包含Razor文件的项目时，观察到以下现象：

1. CPU使用率持续维持在100%左右（在Mac上表现为单核满载）
2. 项目加载时间显著延长（从40秒增加到3分钟）
3. 代码智能感知功能（如CodeLens）延迟出现

通过性能追踪发现，Razor组件在处理项目文件时，会为每个Razor文件和虚拟C#文件发送LSP didOpen/didClose请求。这些请求在语言服务器协议中具有特殊性质，会阻塞其他请求的执行。

技术分析

深入分析性能日志后，我们发现了几个关键点：

1. 路径处理异常：Razor服务器在处理文件路径时出现了重复拼接父目录路径的情况，导致文件查找失败。例如： /path/to/project/path/to/project/Views/File.cshtml

2. 请求风暴：每个Razor文件会触发多次虚拟文件发布操作，服务器不断尝试重新发布相同版本的内容：

   跳过发布C#版本5，因为请求的是版本1
   跳过发布C#版本5，因为请求的是版本2
   

3. 项目信息更新延迟：Razor项目服务在项目加载完成后仍需3分钟左右时间更新所有项目的TagHelpers和C#语言版本信息。

解决方案

开发团队在2.60.26版本中实施了以下优化措施：

1. 减少不必要的LSP请求：优化了虚拟文件发布机制，避免重复发送相同内容的发布请求。

2. 路径处理规范化：修复了文件路径拼接逻辑，确保路径处理的正确性。

3. 异步处理改进：调整了项目信息更新流程，减少对主线程的阻塞。

优化效果

经过这些改进后，实测结果显示：

• MudBlazor项目加载时间从5分钟降至2.5分钟
• 普通项目加载时间减少近50%
• CPU使用率在项目加载完成后迅速恢复正常水平
• 代码智能感知功能响应更加及时

技术启示

这个案例为我们提供了几个重要的技术启示：

1. LSP协议使用：需要谨慎处理didOpen/didClose这类会阻塞其他请求的操作，避免造成请求积压。

2. 性能监控：dotnet-trace工具在诊断.NET应用性能问题时非常有效，特别是配合特定事件收集参数时。

3. 跨进程协作：在多进程架构中（如C#扩展、Razor服务器、DevKit等），需要特别注意进程间通信的效率影响。

4. 渐进式加载：对于大型项目，考虑采用渐进式加载策略，优先处理用户当前需要的功能。

这次优化不仅解决了具体问题，也为后续的架构改进奠定了基础。开发团队正在进行的Razor源生成器工作预计会带来进一步的性能提升。