ReSharper Platform Tutorials 开发工具

ReSharper 高效攻略 – 将 ReSharper 从进程中取出

在上一篇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 Studio正在逐步过渡到带有很多子进程的进程,每个子进程都可以消耗其所需的内存。

这种架构有很多优点:每个子进程都有自己的线程池,可以由操作系统在不同的CPU内核上运行。

每个子进程还有自己的内存空间自己的垃圾回收器

我们的跨平台.NET IDE – Rider中使用了同样的方法,IDE只是UI和宿主进程,而很多繁重的工作都发生在子进程中,这会导致性能发生翻天覆地的改善

运行多个进程的确会带来一些其他挑战。

如何保持同步?

必须处理编辑器中的所有按键操作吗?

当我们键入类名然后删除它时, 它是否必须在两个进程中都存在?

我们在Rider中使用的反应分布式通信协议可能解答了这些问题。

JetBrains正在研究将ReSharper作为Visual Studio的一个子进程而不是主进程的一部分。

异步加载ReSharper VSPackage

在使ReSharper运行自己的进程之后,我们可以改进必须保留在Visual Studio进程中的位的加载

我们仍将可以呈现菜单、显示重构对话框,并跟踪编辑器。

Visual Studio真的只是Visual Studio Shell,它加载很多VSPackage实例,其中包含语言功能和使其成为IDE的具体工具。

几乎Visual Studio安装程序中的每个复选框都代表这类VSPackage,而ReSharper是可以加载的另一个VSPackage实例。

只有当某些上下文需要某个包时,Visual Studio才执行延迟加载

更新的Visual Studio版本也允许异步加载VSPackage,将此工作移动到后台线程。

JetBrains正在研究将ReSharper作为异步VSPackage加载。

结论

在本文中,我们讲述了改进ReSharper性能的一种方法:将它从进程中取出。

 这带来很多好处:Visual Studio和ReSharper都在自己的进程中运行,有自己的线程池和内存空间。此外,我们正在研究在Visual Studio中异步加载ReSharper。但这些解决方案都未达到完美。

还有其他领域可以改进,我们将在下一篇文章中讲述这些内容!

如果您遇到性能问题,切记查看Visual Studio性能指南 (ReSharper 2017.3+),还有我们的知识库文章加快ReSharper(和Visual Studio)

如果您遇到可以重现的具体的性能问题,而且您愿意收集并发送性能问题快照给我们,我们将深表感激。

博客文章将ReSharper从进程中取出 – ReSharper性能系列将在.NET工具博客上首发。

 

image description

Discover more