加速 Visual Studio 2010 / Resharper / ASP.NET MVC 中的编译和单元测试
我正在使用 Visual Studio 2010 和 Resharper 开发一个中型 ASP.NET MVC 解决方案。当我 1 1/2 年前开始开发该项目时，该项目速度非常快，但随着时间的推移，它变得越来越慢 - 不仅是编译，还有 ASP.NET 重新初始化网站所需的时间。由于我经常练习 TDD 和重构，因此我经常需要重新编译并重新运行我的测试，因此我正在寻找可能的方法来缓解这种情况。
问题详情
从开始重新编译项目到能够在网络浏览器中查看结果，我大约花了 20-25 秒。
使用 Resharper 测试运行程序运行单个单元测试（只是单个测试，而不是整个套件）也非常慢（大约 15-20 秒）。由于某些奇怪的原因，Resharper 似乎花费了大部分时间来初始化测试运行，而只花费很少的一部分来实际运行测试。
我已经做过的事情：
- 用 SSD 替换我的硬盘（影响巨大）
- 将 ASP.NET 的编译和 Windows Temp 目录移动到类似 SSD（硬件）的 RAM 驱动器（影响很大，但是那是在 SSD 之前）
- 禁用了我很少修改的一个项目的自动编译（影响很小，因为无论如何该项目都很小）。
- 清除了对 .NET 和第三方库的不必要引用（影响非常小，如果有的话）
- 此博文。 （影响非常小，如果有的话）。
然而我仍然坚持上面的（慢？）数字，我觉得这损害了我的生产力。现在我想知道下一步该做什么。
我当前的系统设置：
- Core 2 Quad Q6600 CPU
- 4GB DDR2 800 RAM
- 120 GB SSD
- Windows 7 x64
- Visual Studio 2010 Ultimate，带有 Resharper 5.5
我的解决方案规格：
- 22.000 行 .NET 4 个 C# 代码
- 3 项目：一个 ASP.NET MVC、一个测试项目、一个小型通用库包含在另外两个项目中，除非发生更改，否则我不会对其进行编译。
- 35 个对其他库（.NET 框架和开源内容）的引用
- ~200 次浏览
- 850 次单元测试
现在我的问题：
- 将我的 RAM 升级到 8GB 是否可以显着提升性能？
- 这些数字正常吗？或者这可能是我的解决方案的问题？
- 接下来您会尝试什么（除了购买一台全新的计算机之外）？
谢谢，
Adrian
编辑：一件特别奇怪的事情是，当我点击“构建解决方案”按钮时，Visual Studio 会花费大约 8 秒的时间向我显示一个等待符号，直到它真正开始编译并且编译窗口正在显示。已更新。在此期间 IDE 无响应。这是实际编译时间的很大一部分。我想知道Visual Studio这段时间在做什么？
I'm working on a medium sized ASP.NET MVC solution with Visual Studio 2010 and Resharper. The project was blazing fast when I started developing it 1 1/2 years ago, but over time it has become slower - not only compilation, but also the time it takes ASP.NET to re-initialize the website. Since I am practicing TDD and refactoring quite often, I frequently need to recompile an re-run my tests, so I am looking for ways to mitigate this if any possible.
The problem in detail
It takes me about 20-25 seconds from starting to recompile the project to being able to view the result in a web browser.
Running a single unit test (just a single test, not the entire suite) with the Resharper test runner is also very slow (about 15-20 seconds). For some weird reason it seems that Resharper takes most of the time initializing the test run and spends only a very small fraction actually running the test.
What I've already done:
- Replaced my hard drive with an SSD (huge impact)
- Moved ASP.NET's compilation and the Windows Temp directory dir to SSD-like (hardware) RAM drive (big impact, but that was before SSD)
- Disabled automatic compilation of one project I rarely modify (Small impact since that project is small anyway).
- Weeded out unnecessary references to .NET and third party libraries (very small impact, if any)
- Some black magic tricks discussed in this blog post. (very small impact, if any).
Yet I am still stuck with the (slow?) figures above and I feel that this is harming my productivity. Now I am wondering what do do next.
My current system setup:
- Core 2 Quad Q6600 CPU
- 4GB DDR2 800 RAM
- 120 GB SSD
- Windows 7 x64
- Visual Studio 2010 Ultimate with Resharper 5.5
My solution's specs:
- 22.000 Lines of .NET 4 C# Code
- 3 projects: One ASP.NET MVC, one test project , one tiny general purpose library is included by the other two and which I do not compile unless something changed.
- 35 references to other libraries (.NET framework and open source stuff)
- ~200 Views
- 850 Unit Tests
Now my questions:
- Would upgrading my RAM to 8GB could give me a significant performance boost?
- Are these figures normal? Or perhaps this could be a problem with my solution?
- What would you try next (apart from buying an entirely new computer)?
Thanks,
Adrian
Edit: One particularly weird thing is that when I hit the "build solution" button, Visual Studio spends about 8 seconds showing me a waiting symbol until it actually starts compiling and the compilation window is being updated. The IDE is unrespsonsive during this period. Thats a good portion of the actual compilation time. I wonder what Visual Studio is doing during this period?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
对于这个尺寸的解决方案，看起来你的硬件确实没问题，并且应该足够快来构建测试。我发现大多数构建性能问题（无论如何就我而言）都与项目依赖项有关，而不是与实际编译时间有关。我有几个想法可以帮助您找出问题：
尝试将“MSBuild 项目构建输出详细程度”更改为“诊断”（选项 -> 项目和解决方案 -> 构建和运行），同时安装 VSCommands 扩展（它包含一个构建统计扩展，显示每个步骤所花费的时间）并检查哪个部分说得最多。
对 GAC 中其他项目（您提到的 35 个）的依赖性，还是分散在您的 HD 中？它们是否自动刷新引用（它们下面是否有 .refresh 文件）。可以尝试简化这些依赖的解析，即将本地所有的DLL复制到bin目录下，看看是否有帮助
For that size solution, it really seems that your hardware is ok and should be fast enough to build-test. What I've found is that most of the build performance problems (in my case anyway) are related to project dependencies and not to actual compile time. I couple of ideas to help you find out the problem:
try turning the "MSBuild project build output verbosity" to "Diagnostic" (Options->Projects and Solutions->Build and Run), also install the VSCommands extensions (it contains a build statistics extension that shows time taken on each step) and check what is the part that is talking up the most time.
Are the dependencies on other projects (the 35 you refer to) in the GAC, or are they scatter through your HD? Are they auto-refresh references (do they have .refresh file underneath them). Maay try to simplify the resolution of these dependencies, ie copy local all the DLLs to the bin directory and see if it helps
您可以尝试秘密的 Resharper.Internal 功能“使用 MSBuild 进行并发构建”，如下所述 此处。
You can try the secret Resharper.Internal feature "Concurrent building with MSBuild" as described here.
由于这是一个 MVC 项目，请确保项目的“构建视图”已关闭。
false
我将其保留，以便编译器在我的客户之前发现我的错误。但构建视图速度非常慢。
Since this is an MVC project, ensure your project's "Build Views" is off.
false
I leave it on so that the compiler finds my mistakes before my customers do. But Build Views is horribly slow.
我有类似的问题。由于我点击了“运行测试”按钮，因此需要一分钟左右的时间才能运行测试。
我的问题是我的测试设置指向
'Trace and Impact'而不是'Local'。要选择测试设置，请转至“测试”菜单，然后转至“选择活动测试设置”。本地'。
这对我有用。
I had a similar problem. Since I hit the
'Run tests'button it took a minute or so to have the test running.My problem was that I had the test settings pointing to
'Trace and Impact'instead of'Local'.To select test settings, go to
'Test'menu and then'Select Active Test Settings > Local'.That worked for me.
您可以设置一个将运行的构建服务器：
您必须等待大致相同的时间才能看到新版本上线，但它不会消耗您的开发 PC 资源。
You can setup a build server which will run:
You'll have to wait roughly the same amount of time to see the new version go live, but it won't consume your development PC resources.
这里有类似的问题，我打开了“代码覆盖率”。
Similar problem here, I'd left 'code coverage' turned on.