唐山seo网站建设,做网站切图,网站建设是系统工程,帝国网站 教程本文要点
.NET自4.0以来得到了大幅的性能提升#xff0c;很值得重新考虑一下基于旧版本.NET框架所做的假定。在讨论性能时垃圾回收是个重复出现的主题#xff0c;它带来了许多CLR和语言的提升#xff0c;比如引用返回和ValueTask在内存分配上更细粒度度量的性能分析API会成…本文要点
.NET自4.0以来得到了大幅的性能提升很值得重新考虑一下基于旧版本.NET框架所做的假定。在讨论性能时垃圾回收是个重复出现的主题它带来了许多CLR和语言的提升比如引用返回和ValueTask在内存分配上更细粒度度量的性能分析API会成为对当前版本API的最大改进目前正在开发。.NET包含有很多丰富的并行编程API和类库比如Task Parallel Library、Rx.NET 和Akka.NET。这一领域的挑战在于教育用户以及为使更广泛的社区轻松使用而所做的抽象。.NET作为一个生态环境具备支持物联网或小型设备的必要构件.NET Native、.NET Standard 以及便捷CLR 组件。
随着.NET Standard 和对.NET应用开放的新平台的出现近期大家对.NET的性能越来越感兴趣了。在传统认知上.NET不是一个编写高性能应用的平台而通常会把它和企业级应用联系在一起。
近几年有几个正显著改变这一状况的趋势。首先也是最重要的是.NET Standard 为许多各种不同的平台打开了大门比如移动电话和物联网设备。这些设备提出了新的挑战资源的约束会比桌面和服务器多得多。
同时能够在Linux上运行服务端应用也向开发人员展示出极重要的机会和未知的领域。.NET Core还有待积累运行高性能应用的成功案例。在.NET生态环境中正在呈现出几个新的趋势微服务、容器和无服务器。每个都带着他们自己的性能需求。
讨论组成员
Ben Watson - 《编写高性能.Net代码》和《 C# 4.0 How-To》的作者Sasha Goldshtein - Sela Group的技术总监、微软C# MVP和区域主管Matt Warren - 热爱寻找和修复性能问题的C#开发人员Maoni Stephens - .NET GC的核心开发人员Aaron Stannard - Petabridge的创始人和技术总监
InfoQ以你们的经验来看在性能方面.NET处于什么位置它和其他主流平台相比如何
Ben Watson: .NET 处于强有力的位置而且在不断变强。CLR团队对性能总是非常关注最近几年提升了.NET许多方面的性能比如运行时编译和垃圾回收。在微软我的产品已经推动了一些这种改变很高兴看到这些改变能对整个世界有益而不仅仅是微软那些大型应用。
当然也有一些弱点。在线上的世界里每个请求都很重要像运行时编译和垃圾回收会妨碍取得极致的性能。也有解决办法但需要很大的工作量那么就要看这最后一丝性能对你有多么重要了。
性能永无止境任何平台都是在做权衡。.NET给了你一些运行时难以置信的特性但你必须按它的规则去充分利用它。最好的性能需要最好的技术努力。其他平台会有不同的权衡但无论如何技术努力都是不可或缺的。
Sasha Goldshtein过去大家都认为.NET是针对大型企业和Web应用的平台它们的性能不像游戏、嵌入式系统和实时消息处理那么重要。我认为最近几年这种看法发生了改变因为更多的人开始认知到C#和F#的便利以及.NET框架的强大功能和在非软件操作系统上使用同一代码库的潜在能力使得投身于使用.NET开发高性能系统值得去做了。
微软在平台性能上做了相当大的投入。举些例子几年前已引入.NET Native以改善启动时间和减少客户端app的内存使用.NET 4.5 和 4.6对垃圾回收的伸缩性做了重大改进.NET 4.6 改造了运行时编译器使其支持向量化了C# 7引入了引用局部变量和引用返回这是一些旨在让语言层有更好的性能的特性。
总而言之可能对于我个人而言是可以更容易地用C或C这样的低级语言来编写小型高性能应用了。然而若想把非托管代码引入到已有的系统中或使用这些语言开发大型数据库还需要慎重考虑。对于某些特定类型的高性能系统把宝押在.NET上还是可行的只要你意识到相应的风险并具备在代码层解决它们的工具并且可以应对生产环境中出现的问题就可以了。
Matt Warren: .NET经常被拿来和Java比较因为他们有非常相似的运行时也就是说他们都有运行时编译器、垃圾回收并支持类似的面向对象的语言C# v. Java。我想说的是这两个运行时有着同样的性能特点但当然也各有所长。
大家经常说Java Hotspot CompilerJIT性能比.NET JIT更为优化。此外它还有一些对性能有所帮助的额外特性例如它将在一开始解释一个方法为改进启动时间然后可能在稍后再编译为机器码。
然而在另一方面现在.NET已经支持自定义值类型结构有很久了它能让你更好地控制内存层并有助于减少垃圾回收的影响。Java在不久的将来可能会有自己版本的值类型但目前还没有。
我认为.NET是一个稳固的平台它在各个方面都做得不错。它总被打上比某某平台慢的标签但我觉得对于它适用的负载类型它的表现还不错。
Maoni Stephens讨论性能时往往都会提到垃圾回收。因为我就是从事这方面工作的所以我在此次座谈会上的回答将更多地围绕垃圾回收的上下文来展开。虽然在有些人的印象中.NET具有高生产力而性能一般但是其实已经有很多由.NET写成的具有高性能需求的产品。为确保我们的垃圾回收能够处理这些需求我们在交付重大特性之前总会由内部合作伙伴来测试它让它来处理现实中最具压力的负载比如必应或 Exchange。我们不只是靠基本和大型基准测试尽管它们非常有用但严重缺乏在现实世界中性能的正确表现。.NET垃圾回收这十几年来已经做过大量的调整与其他主流平台相比已经非常有竞争力了。
当然垃圾回收只是框架的一部分。当有些人讨论垃圾回收性能时其实是在说“垃圾回收是如何来处理我给它的工作负载的”。如果工作负载把许多压力都放到垃圾回收上自然会比没那么大的压力情况产生更长时间和/或更频繁的垃圾回收暂停。从历史角度来看.NET框架实现的方式和大家用.NET编写代码的方式往往会很容易把非常重的压力丢给垃圾回收。虽然我们一直都在改进我们的垃圾回收但具有高性能需求的人也需要不停去度量和分析什么因素正在影响着他们应用的性能。这和你在使用什么框架或类库无关换句话说如果你想要达成和保持高性能就需要去搞清楚你的工作负载是怎样的表现。如果你对垃圾回收很感兴趣可以阅读这篇博客里面仅对垃圾回收的比较做了阐述。
实际上垃圾回收是向成熟框架提出的一部分挑战而较新的框架可能不需要面对这些挑战。我们已经有了许多写完并用了很久的类库通常我们很难用新特性去打破现有的局面。即便我们要实现哪怕只有一小部分愿意为高性能投入更多精力的用户使用也要尽可能保证其像框架的主要特性一样可靠。我看到一部分新框架推崇能够测探性能的特性但这实际是把不切实际的可靠性负担甩给了用户。那不是我们想要采取的方式。
我们的客户总要求我们拿出更好的性能因为他们这方面正在超越极限我听到许多过去常常使用.NET的人说当他们由于工作变动而不得不切换到其他框架时其实真的很想念它。所以现在.NET能运行于更多的操作系统令我非常地兴奋。就像之前所说的鉴于.NET类库和应用的编写方式往往会给垃圾回收产生大量的工作所以我认为我们需要在可预见的未来时间内不断地改进垃圾回收的性能以及制作能帮用户度量性能的工具。与此同时我们也在考虑研发更多能够降低垃圾回收压力的特性。
Aaron Stannard大多数“性能”差异归根结底在于框架的顶层实现。出于很多原因JavaScript不是个“快速”的语言然而在所有TechEmpower 基准测试中Node.JS都把ASP.NET抛在了身后。为什么主要原因是ASP.NET采用的是几十年前特定于Windows的老技术最初的实现采用的是一种同步的设计思路。而另一方面 Node.JS一开始就设计为异步的了而且从开始到现在采纳了许多其他性能优先的选择。
即便ASP.NET可能是慢的但C#语言和CLR本身是非常快的。CLR支持值类型与JVM相比这是性能方面的巨大优势因为我们可以从本质上释放为这些类型分配的内存在一定程度上……。CLR近几年已经有了很多的改进使它在运行期“聪明”多了。例如垃圾回收器已经可以在回收垃圾时对内存进行很好地碎片整理了这样对后续内存访问的速度提升有显著的帮助。CLR JIT也可以使用性能分析信息决策如何在运行时最好地编译本地函数比如是否使用转移表或简化C#接口上只有少量代码实现的if语句。
C#语言本身还具备一个好处那就是能够让开发人员对编译器工作有更多的控制权你可以提供关于内联函数的指令你可以把内存锁定到空闲的堆上和垃圾回收范围之外如果需要你甚至可以将CLR分配对象视为不安全的回溯C风格的指针运算。由于指针的存在相比任何其他托管的语言使用C#和CLR进行性能方面的调整都会更加灵活。
InfoQ你们用.NET编写高性能应用时所面对的挑战是什么
Ben Watson最大的挑战在某些方面来说仍旧是垃圾回收。当大多数人首次开始用.NET编程时会觉得这是理所应当的不去管它。对于大多数应用来说它确实无关紧要除非你的内存分配模式非常糟糕。
然而垃圾回收问题不应被忽视特别是在永不停机的高性能系统中。像此类程序的编写与基础应用完全不同。例如当你默认编码模式导致每秒分配几GB的内存分配时如何调整使你的程序不再是垃圾回收机制的主要诱因呢如果你每毫秒都计数它什么时候有时间去回收呢
不是说你要完全避免垃圾回收而是说要使它的成本尽可能小使它不会有太大的影响在性能分析中不再是最突出的问题。为做到这一点可能需要非常大量的技术工作但结果会令人吃惊的。实际上在托管代码中也有可能达成像在非托管代码中的性能技巧虽然不同但办法总是有的。
做这件事需要从根本上转变大家编写托管代码的思维大家必须对得起工程师的名号。在某种程度上这种技术思维的转变是最难的部分。我们经常不把自己的工具当回事当性能真正重要时却无能为力了。
Sasha Goldshtein就像使用任何托管的平台一样垃圾回收器是许多.NET应用变慢或暂停的源头。当堆变大时达成几十甚至几百GB鉴于.NET没有完全并行的回收器所以某些收集需要把应用的线程完全挂起这就与管理感应式垃圾回收有许多不同了。结果许多人伸手就用非托管的内存、把对象放到缓冲池里却不再释放或者为了不出现完全的垃圾回收而非常小心地调整系统。这很令人遗憾在我看来垃圾回收应为应用开发人员服务然而有时却本末倒置了。
性能挑战的另一个来源是潜伏在各种C#语言结构和.NET类库API中的各种地雷。例如通常很难预测哪个类库方法打算分配内存或者如何以最小内存分配的方式来使用语言结构。
最后在 C/C 中仍然很容易去做一些操作比如指针处理、高级的向量目前System.Numerics.Vectors中已不再涵盖、一般计数代码。在C#中得到同样的结果经常需要些反常的结构比如不安全的代码从模版生成的代码甚至动态生成的IL或汇编代码。
Matt Warren在我之前工作过的几个项目里对垃圾回收影响的处理很成问题。持续运行数小时或数日的系统会分配大量的内存在某一时刻垃圾回收不得不去彻底清理。因为该应用有着非常严格的隐含需求低于40毫秒所以这些暂停就成了问题。那么学习如何去检测、度量和缓解这些垃圾回收的影响就成了我们最大的性能挑战。
Maoni Stephens垃圾回收是由内存的分配和残留引发的。我们想要帮框架程序集的作者和客户找出与此相关的信息继而使垃圾回收的作业更加简单。这些年我们与客户探讨过展现内存分配的几种思路。我记得有一次我们探讨了提供“内存分配打分”的API但这没那么简单因为当你采用不同的参数或执行不同的代码路径时会有截然不同的内存分配。当然我们已经开发了能对你的内存分配有所帮助的工具我们有ETW事件和以贴切的方式呈现这些事件的工具但如果能在我开发的时候就让我看到调用一个API会分配多少字节的内存或者从A点到B点我已经自己分配了多少字节的内存那就更好了。运行时可以提供这些信息但我还没看到有IDE可以做到这一点。
我们所从事的另一件事是PerfView中一个能帮助查看旧一代对象是如何持有新一代中对象的也就是说使它们留存下来。这是短垃圾回收成本的重要部分。我想我们还没有将其推向大众但代码在PerfView里了感兴趣的话可以查看CROSS_GENERATION_LIVENESS因为我们还没有时间使此实现足够稳定。它能让你找出可以设置为null的对象的域让垃圾回收在自然发生时知道你已经不再持有它们的生命周期。
Aaron Stannard总之我发现基础CLR本身在性能工具方面还落后于其他平台。这也是我编写 NBench的其中一个原因它是一个针对.NET应用的性能测试框架。
举个例子Java运行环境暴露Java管理扩展JXM工具链接这使开发人员可以非常容易地访问到详细的性能统计通过图形界面或者JMX API都可以。许多针对大规模JVM应用的管理和监控工具都是直接以此为基础开发的立刻进入脑海的一个例子就是针对 Apache Cassandra的DataStax OpsCenter。退一步说你至少不能不经度量就去讨论性能是“好”、“坏”或“更好”吧在我的经验里在CLR上这么做可是个很痛苦的经历。
目前针对.NET性能的内置解决方案是Event Tracing for Windows (ETW)和性能计数器与JMX相比在一定规模上实现正确性和可靠性还是有点难的。你可能无法在.NET Core中使用它们因为它们是特定于Windows技术的据我所知目前这种监控.NET Core应用的内置选项还不多。
我用.NET开发高性能系统遇到的其他大的挑战是去弄清楚我所依赖的其他.NET类库和组件的性能。因为大多数开发人员不清楚如何去对他们的代码进行性能测试乃至性能分析所以在任何时候把第三方类库引入到自己的应用中都要冒着很大的风险。我记得在我其中一个大规模.NET应用中(每天数百万个事务)安装了一个StatsD监控组件这个类库让我的CPU利用率飙升了百分之三十左右。结果是它用底层UDP端口做了些很怪的事我不得不给修复它好让性能回到之前可接受的水平。
InfoQ.NET在处理并行和并发上做得怎么样有重大改进的空间吗
Ben WatsonTask Parallel LibraryTPL任务并行类库是该平台的一大飞跃。它完全转变成了.NET中的并行编程。我们在线上平台中使用它开发了一个处理实时查询的高扩展性应用。若要得到更好的性能正确编写的TPL应用仅通过增加更多的处理器就可以很简单地进行扩展了实际上我们多次发现都不需要修改代码。
即便如此编写高扩展性系统仍然是一个非常难的事情。它需要深入理解硬件、操作系统以及CLR的内部构件。你的期望越高就越需要慎重考虑每一层。
它正朝着更高、更容易开发的方向抽象但仍未达到初级程序员就可以高效准确使用的程度。
从实用的角度来看实现完美并发经常与避免潜在的阻塞调用有关。在这个领域工具还有些改进的空间。我们需要更好的方式来强调代码中有问题的区域并建议消除这些性能障碍的方式。除非你正在用高度结构化的框架编码限制你的一样做法否则很容易就会因为不慎重地使用公共API而破坏了性能。如果我们可以把平台和此类工具结合帮你担起并发的重担我想这能极大地帮助大众简单有效地使用并发。
Sasha Goldshtein.NET框架有丰富的并发并发APITask Parallel Library、TPL DataFlow以及 async/await语言特性。这些包括数据并行当你想要并行获取大规模条目并进行特定转换时以及无结构的任务并行当你有一组想要安排进一个管道并发执行的任务时。最后还包括有一些好的异步I/O操作它们对于高性能服务端代码来说极为重要。
然而在GPGPU上还没有太多的进展为使.NET应用可以分流通用计算到GPU在混合方面有像Xeon Phi这样的内部处理卡而在向量方面有比当前的System.Numerics.Vectors更先进的向量指令。使用.NET编写高并发的计算密集型应用仍受限于主流处理器受限于插槽和核相对较少如果你把混合计算引擎添加到系统中就变成非常难了。
Matt Warren我们在.NET中很幸运里面有许多可能帮到我们的语言和运行时特性。async/await关键字、Task/Task乃至经过大量调优的线程池。然而看起来这样的重大改进现在正在不断进入高层类库例如实现“Actor”并发模型的Akka.NET 。
Maoni Stephens在V1.0中我们交付了Server GC模式一种并行GC和 Workstation GC模式一种非并行但在一定程度上是并发的。在V4.0我们演进了Workstation GC使其有更强的并发然后在V4.5中使其可用于Server GC了也就是Background Server GC所以它已经同时支持并行并发了这让我们可以极大改进大规模服务器负载大内存堆上的完全垃圾回收暂停从gen2的数秒阻塞降到了通常Background gen2的10毫秒。我们一直都在不断地改善已有的垃圾回收我们还将引入重大改进以帮我们消除一些障碍比如降低完全阻塞垃圾回收的频率到非常低的程度使大多数人不再担心这一点以及在不牺牲太多吞吐率的情况下真正缩短暂停时间。
Aaron Stannard.NET有一些并行并发的最佳工具Task and Parallelism Library (TPL)、 async/await、asynchronous garbage collection、reactive extensions (Rx)以及许多像Akka.NET之类的OSS类库。
改进空间总是有的例如当前为TPL添加的ValueTask类型它让一些任务可以返回自由分配的内存这有非常大的好处。
这让我想起了并行并发里其中的一个重要部分即从性能角度来看可以改进的一个地方是教育我们的最终用户如何更好地使用这些工具。关于async / await 有一个货船崇拜的神话特别是现在导致有些开发人员认为async是一个用于“高速模式启动”的关键字于是就产生了如下的代码块
await Task.Run(() {// 不会从并发得到任何好处的代码
});
await Task.Run(() {// 不会从并发得到任何好处的更多代码
});
并发和并行不是魔法它们是为了提升效率而必须要适当应用的思想。.NET作为一个生态环境没有强调这些要点的学习因此我们中那么多人尽管采取了这些神奇的工具却构建了缓慢和浪费资源的应用。所以换句话说关于这些高性能和并发技术的文档和言传身教极为重要然而如今的交流却忽视了它们实在令人扼腕。
InfoQ与桌面.NET框架相比.NET Core在性能层面带来了什么优势吗
Ben WatsonCLR的基础部分也是对性能影响最大的部分。我觉得.NET Core最大的优势是“真爱在这里”注意力都集中在这里了。桌面 .NET不是事后的想法但是确切来说是能更清楚地预计到会有更多人转到.NET Core。如果有缺陷需要修复或者改进需要实现那么首先会在.NET Core了中处理然后才在相对缓慢的.NET更新发布时间表中予以考虑。
Sasha Goldshtein尽管.NET Core和桌面.NET都来自于同一个共享的代码库但是在.NET Core中有许多创新和优化的机会因为它有更快的发布节奏。然而如果你比较.NET Core 和桌面.NET两个时间点的版本它们来自于同一个代码库我不觉得你会认为有性能差异其内部是相同的C#编译器、相同的JIT和相同的垃圾回收引擎。
Matt Warren幸运的是微软正好写了一篇名为“.NET Core中的性能改进”的博客里面介绍了一些当前的优势。有些改进方法可能曾在.NET框架中出现过基于向后兼容的考虑但它表示当前的.NET Core是领先的。
看起来社区的帮助因为它会开源加上能够比.NET框架更加快速地迭代意味着在.NET Core.中会实现更多的改进。
我可以想象往后差异会越来越大也就是说越来越多的性能改进将只出现在.NET Core中特别是如果他们还新增额外的API的话。
Maoni Stephens所有.NET SKU共享同一个垃圾回收垃圾回收POV的最大优势在于你实际上可以在Core中快速完成一个特性让大家去试用因为它是开源的而不必等到下一个桌面版本才提供给所有的客户。
Aaron Stannard巨大成功。已实现了对Spans、System.IO.Pipelines和许多基础.NET类型比如字符串工作方式的改进这是针对这些类目前在传统.NET 4.*框架上工作方式的所有重大改进。还实现了像ConcurrentQueue这些工作方式的根本性改进这应该有助于显著提升并发应用的速度。
InfoQ在高性能领域.NET Native扮演着什么角色呢在什么情况下它能胜过托管的副本
Ben Watson.NET Native 有许多潜力。通常在移动设备场景和Windows商店应用中它非常有用在那儿你可不想使用用户有限的电池寿命进行运行时编译。然而我很想看到此类技术传播到传统桌面和服务端应用每台机器一次又一次地在运行时编译同一个东西会造成大量电力、故障时间、延迟时间等方面的浪费尤其是数据中心更为突出。NGEN有严苛的限制.NET Native最终可以解决的。
Sasha Goldshtein.NET Native是一个很有意思的项目因为它把完全的静态提前编译(AOT ahead-of-timecompilation)带进了.NET的世界。我说“完全的AOT”是因为NGen从一开始就已经是.NET框架的一部分了但它仍然需要完整安装.NET框架需要用于元数据的原始解释语言模型以及可以根据需要开启运行时编译。
不过最重要的是.NET Native构建所做的优化步骤比基本运行时编译或NGen要先进得多实际上使用了像C一样的后端优化。这并不奇怪因为运行时编译是在非常严格的时间约束下运转的然而.NET Native编译会为一个复杂项目花几分钟。最终结果很让人震惊对于计算密集型应用应用更好的优化某些部分能大幅提速而通过减少需要从磁盘加载的依赖和类库以及使用运行时编译能提升启动时间。
Matt Warren.NET Native 的其中一个好处是你的代码是提前编译的而不是在运行时由JIT编译器编译的。还有两个好处一个是因为在运行时编译的场景中所以启动时间比较快但首次被调用的方法必须予以编译这会带来开销。第二个好处是静态提前编译器可以做更加昂贵且大范围的优化而这在JIT中是不可能的。JIT编译器无法进行这种尝试因为它必须在限定的时间里进行工作而AOT编译器则不受此约束。
Maoni Stephens.NET Native减少了启动时间和磁盘占用。因为它使用了一个做整体分析的编译器它能够执行更多的优化。我认为在容器的应用场景中它会成为重要角色。
Aaron Stannard从部署的角度来看.NET Native会比较方便因为它让用户可以部署.NET应用到从未安装过.NET运行环境的机器上这有点儿像静态编译过的C应用。但我觉得这么编译出来的应用在性能上比不上它的托管副本。本机编译的应用不能充分利用JIT的运行时性能分析它本来可以让应用基于实际在运行时的使用情况自己做出性能调整的。.NET Native应用应该比总是需要.NET JIT的应有更短的启动时间但我觉得即时编译的应用的运行时性能通常会更好一些。
InfoQ最近.NET语言里添加了几个性能相关的特性比如值元组和引用返回。你们觉得接下来会看到什么特性
Ben Watson我很想看到在高吞吐率场景下缓冲对象以降低内存分配率这一方面的进展。我知道许多缓冲内部数据结构以降低内存加载的.NET API即便一些官方设计指南很有帮助但这种缓冲技术应用于非常特殊的用途。一些CLR恰恰可帮你轻松创建简单可复用的对象减少垃圾回收上的开销。
我还希望看到更具伸缩性的JIT。它不慢但是在多核上即时编译代码会有瓶颈它使你无法在运行大型应用时把初始化时间降到最低。
Sasha Goldshtein我希望C#能够在数字类型上或者不共享接口的其他任意家族类型上使用真正通用的代码。我想到了C模版因为你可以创作一个对任意数字类型或家族类型有作用的函数模版而不必预先规定限制条件。不幸的是看起来引入此类特性需要在CLR方面做出改变而涉及语言设计是个非常谨慎的事自CLR 2.0引入泛型以来就在尽量避免变动。
尽管我可以理解这些版本但我仍然希望看到另一个特性那就是在C#编程中内联解释语言甚至是内联汇编。这会为进一步优化、向量指令和其他硬件相关的优化打开新的大门。
Matt WarrenSpan虽然我知道它们即将到来但其实可能只是个说辞能够高效访问接近或匹配数组的“任意内存的连续区域”是最大的好处。一旦他们是在运行时实现的我们就会看到Span广泛应用于所有框架和第三方类库这将发挥非常广泛的作用。
Maoni Stephens我们在垃圾回收上的哲学已经极少有旋钮了因为我们认为用户不应该为了调优内存而去花很多时间精通垃圾回收的知识这应该是我们的工作。我们只为用户提供了几个配置告诉我们他们的应用是什么类型就可以了比如是服务端还是客户端。我们一直都在遵循这个哲学。我们想提供更多的配置让客户告诉我们发应用性能上下文中如何帮助他们例如他们的应用是否想要用更大的堆换得更可预测的暂停或者在机器上有64GB的内存但是他们希望某一进程只使用32GB。我们正在增加能对糟糕局面做出更好反应的新机制和策略以使垃圾回收更为健壮那么我们就可以满足这些配置的要求了。这是垃圾回收团队在不久的将来将交付的下一个与性能相关的其中一个特性。
Aaron Stannard我希望看到一些基本的集合能够原生支持引用返回从性能角度来看这样能带来一些真正有趣的可能性使之能够传递引用到相同的值类型或一系列这种类型的迭代器。我不知道可能会有什么性能收益但我希望可以进行实验得出结论。
不过我希望看到的最大特性是用于.NET Core的跨平台的性能工具。我也需要能够得到在Linux运行环境中垃圾回收以及其他CLR核心部分的运行时性能指标
InfoQ虽然高性能通常与服务端应用有关但移动和物联网设备之类的其他平台也提出了独特的性能需求。.NET可以满足这些非传统平台的需求吗
Ben Watson我持乐观态度我们将把.NET看作为一个用于小型和更多独特设备的优秀平台。我们正看到.NET更多的模块化方法在此各种组件可以按需增增减减或者替换。随着日趋成熟我觉得我们将看到一些用于不同设备的非常适当的架构。
在许多方面我认为今后的高性能应用.NET及其他在于适当的创建以及具有约束的可复用框架通过这些约束实现高性能模式。
Sasha Goldshtein移动和物联网方面它们非常关注于快速启动时间、更少的内存占用以及面对垃圾回收的决定性性能。这个领域还有些工作要做比如.NET Native而在减少垃圾回收暂停或削减.NET应用内存大小上普遍没有太大的进展。我现在担心如果它偶尔来次5秒种的垃圾回收那就很难用C#做物联网应用了而高性能的移动应用也存在同样的问题。未来在.NET Core和CoreCLR上性能方面的工作必须考虑到这些非传统性需求。
Matt Warren要使.NET运行于其他平台比如树莓派和三星的Tizen OS还有许多工作要做迄今为止看起来.NET运行时调整得不错。针对更多受限的设备做出改变多么有意思呀比如降低内存开销所以我们全是受益者
Maoni Stephens机理通常都已经有了。我们需要做些性能调优使它们可以更好地应用于其他的平台。举个简单的例子当电话开始使用Core时我们需要针对Workstation GC减小段的大小。UWP应用往往会使用更多的垃圾回收句柄这意味着我们可能需要使我们的垃圾回收句柄代码路径更加优化。这些事需要我们去收集数据它对于我们决定优先级非常重要。
Aaron Stannard在我们公司已经有客户将.NET用于高吞吐率的物联网应用了。现在甚至都用不着.NET Core。我期待随着.NET Core运行时的成熟和更多的类库开始支持它会发展得越来越好。在移动这一方面随着Unity3D迁移至新版本的C#和Mono运行时顺便一提它也快得多了从我们的基准测试结果来看它已经接近Windows桌面CLR的水平我期待看到Unity3D应用的性能有显著提升。
总结
自.NET4.0以下.NET及其语言在性能方面已经有了显著的发展使古老的假设成了过去式。除了垃圾回收、JIT和BCL方面的改进.NET Native之类的新增内容和TPL还拓宽了可用.NET处理的应用场景。许多已列入计划或正在实现的改进证明它们一直在密切关注升级和新的基准测试。
关于作者
Ben Watson 从2008年以来已经是微软的一名软件工程师了。必应是世界领先的、基于.NET的、高性能服务端应用之一它通过数以万计的机器为无数客户处理着大量低延迟请求他作为必应平台的核心开发人员在该平台的建设中起着不可或缺的作用。他是性能的狂热追求者花了很多的时间在教育团队高性能.NET的最佳实践上。在他闲暇的时间里喜欢享受地理寻宝、乐高、阅读、古典音乐陪伴妻子和孩子在美丽的太平洋西北部度过美好时光。他是《编写高性能.Net代码》和《 C# 4.0 How-To》的作者。
Sasha Goldshtein 是Sela Group的技术总监、微软C# MVP和区域主管、Pluralsight的作者以及国际咨询师和培训师。他是《Introducing Windows 7 for Developers》微软出版社2009年和《Pro .NET Performance》Apress出版社2012年的作者他是一名多产的博客写手和开源贡献者开发了许多著名的培训课程其中包括.NET 调试、.NET性能、安卓应用开发以及现代C。他的咨询工作主要围绕分布式架构、产品调试和性能诊断以及移动应用开发。
Matt Warren是一名C#开发人员他最喜欢的就是发现和修复性能问题。他与Azure、ASP.NET MVC 和 WinForms合作过一些项目比如用于存储政府气象数据的网站、医疗监控设备以及一个确保啤酒桶没漏的检测系统他是一名BenchmarkDotNet和CoreCLR的开源贡献者。Matt目前主要忙着在CA Technologies做C#产品分析工具和在www.mattwarren.org写博客。
Maoni Stephens 是.NET GC的主要开发人员。她在闲暇时喜欢阅读垃圾回收方面的论文和观看日本动漫或动物世界。平时她喜欢使她关注的事情更加高效。 Aaron Stannard 是 Petabridge的创始人和技术总监这是一个.NET数据平台公司。Aaron是Akka.NET最初的贡献者之一他编写了Akka.Remote module 和 Helios底层socket中间件。在从事Petabridge的事业之前Petabridge Aaron 创立了MarkedUp Analytics一个针对应用开发人员的实时应用分析和营销自动化公司他们的底层借助了Cassandra和Akka.NET。
原文地址http://www.infoq.com/cn/articles/high-performance-dotnet .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
