在前一篇ReSharper性能系列文章中，我们已经看到将它作为一个单独的过程来运行是很有意义的。 这带来很多好处：Visual Studio和ReSharper都在自己的进程中运行，有自己的线程池和内存空间。 但这本身并不是修复性能的最佳方案。这是个很广泛的问题，但还有其他可以改进的领域。 我们将在本文中研究如何改进Visual Studio和ReSharper的启动。 在本系列中： ReSharper性能简介系列 将ReSharper从进程中取出 组件合成、即时编译、UI线程 ReSharper 2018.1和2018.1.1的性能改进 开始吧！ 组件合成 Visual Studio实际上是Visual Studio Shell的组合，提供VSPackages中定义的通用函数和主机模块，以及一些提供C#编辑、web工具、Azure工具、WPF设计器、重构工具等等的VSPackage。 所有这些组件都必须在某些点上加载，并且经常依赖于其他组件。 Visual Studio使用托管扩展性框架（MEF）来确定加载顺序和指定组件的相互依赖性。 ReSharper就是其中的一个组件，但也有自己的组件模型。拥有我们自己的组件模型有几个原因： 我们有许多独立产品，比如：dotPeek、dotMemo

在上一篇ReSharper性能系列文章中，我们讲述了Visual Studio和ReSharper的复杂性和历史，并确定了性能下降的原因之一在于Visual Studio是32位进程。在本文中，我们将会讲述如何克服这个限制。 在本系列中： ReSharper性能简介系列 将ReSharper从进程中取出 组件合成、即时编译、UI线程 ReSharper 2018.1和2018.1.1的性能改进 让我们深入了解一下吧！ Roslyn和ReSharper 我们已经研究了32位进程的局限性，并且明白只有这么多内存可供消耗。  因此也许有人会问：为什么JetBrains仍使用ReSharper构建自己的语言引擎呢？ 为什么不只用Roslyn，这样内存中就只有一个而不是两个引擎了？而带来的好处是，也许ReSharper开发会变得更快？ 不这样做的原因有很多，如我们在ReSharper和Roslyn Q&A中所述。  一个更好的问题是：为了解决32位工作集的限制而更换一台润滑更好的引擎是否值得？还要过多久，这种更换也会遇到边界限制？ 当然有更好的办法…… Microservices! （微服务） （采用子进程的形式） 如何克服可用内存的限制？和所有事情一样，答案是微服务。 Visual Stu

每次ReSharper更新后，我们都会收到关于其性能的一些问题。 有的用户注意到到加载解决方案略有些慢，有的发觉索引有些滞后，还有的看到一条黄色通知栏，上面说明 “JetBrains ReSharper Ultimate’ likely caused 9 seconds of unresponsiveness. Disabling it may improve your experience.” – 是的, 我们还见到过更高的值。 我们听到了您的意见，我们用ReSharper来开发ReSharper。也许并不总是那么明显，但我们正不断努力改善ReSharper的性能。 因为这些改进并不总是为人所知，于是我们决定开始发布一系列博客，讲述关于正在发生的这些大小改进。 我们将接触到一些高层次的东西，还会揭示一些幕后的东西。 在本系列中： ReSharper 高效攻略 将ReSharper从进程中取出 组件合成、即时编译、UI线程 ReSharper 2018.1和2018.1.1的性能改进 请注意，这些博文会很长 – 会涉及很多上下文。所以，让我们从头开始，先回顾一点历史！ Visual Studio 和 ReSharper Visual Studio为很多开发人员提供了跨Windows、Web、多个云和移动平台