大学IT网 - 最懂大学生的IT学习网站! QQ资料交流群:367606806
当前位置:大学IT网 > C#技巧 > c++的性能, c#的产能?!鱼和熊掌可以兼得,.NET N

c++的性能, c#的产能?!鱼和熊掌可以兼得,.NET N(2)

关键词:熊掌兼得产能性能初窥  阅读(1399) 赞(20)

[摘要]本文是对c++的性能, c#的产能?!鱼和熊掌可以兼得,.NET NATIVE初窥的讲解,与大家分享。
之后点击Run static native analysis 会出现This application is compatible with .net native code generation。

位置在release folder下:

下面有不使用.net native后release folder大小:

使用.net native后。拿掉 说明.net native网页文件夹后 可以部署的文件大小:

明显编译后还是小很多的。第一次使用,可能对其中文件和一些部署相关还不够了解。有错希望指正!。

之后会出更详细的评测。希望大家持续关注谢谢!

  假如还有问题,这个链接也许会解决您的疑惑:

  http://msdn.microsoft.com/zh-cn/vstudio/dn642499.aspx

是否支持 F# 或 VB 或我最喜欢的语言?

此预览版仅支持 C# 代码,因为它是大多数应用商店应用使用的 .NET 语言。但在我们拓宽工作重点之后,毫无疑问,我们会支持所有 .NET 语言。

此产品是仅与性能有关,还是也允许生成针对 Win32/64 本机编译并且不需要在目标计算机上安装 .NET Framework 的 C# 代码(举例来说)?

没错:.NET Native 不仅仅与性能有关,而且与工作效率和一致的设备体验有关。利用 .NET Native,您能够使用托管语言编写代码并且能够像往常一样上载 MSIL 包。但是,应用将作为完全自包含的本机编译代码部署在最终用户设备上(当 .NET Native 进入生产时),并且不依赖目标设备/计算机上的 .NET Framework。如您所知,.NET 应用程序的范围很广。因此,我们对完整的 .NET Framework 也进行了重大投入(例如,我们刚刚发布了 RyuJIT 的 CTP)。

设计此产品时考虑了哪些方案?

我们考虑过的方案是用于设备的应用商店应用 - 使开发人员能够保持 .NET 和 MSIL 的工作效率优势并且能够将 MSIL 包上载到应用商店,为最终用户提供性能类似的本机代码 (C++)(与 Windows Phone 8 类似,在云中进行编译)。

.NET Native 是否将取代 .NET Micro Framework 以及 C#/.NET 是否将完全可供小型设备使用?

.NET Native 当前的重点是 Windows 应用商店应用。Micro Framework 由 Windows Embedded 团队交付,.NET 团队与他们一起携手为客户提供最佳服务。

开发人员预览版是否适用于创建 Windows Phone 应用和库?

可以创建与 .NET Native 一起使用的通用类库。在此预览版中,仅 Windows 应用商店应用可使用 .NET Native 进行创建。正在实现使用 .NET Native 开发 Windows Phone 应用。

此产品能否提高 C# 开发人员开发高度图形化的应用和/或游戏的体验?

可以。.NET Native 编译器与 Microsoft C++ 优化器共享部分基本代码。

服务器/桌面应用是否将受益于 .NET Native 和/或云中的编译器?

桌面应用是我们策略中的非常重要的部分。最初,我们的重心是 Windows 应用商店应用与 .NET Native。从长远来看,我们将继续改进所有 .NET 应用程序的本机编译。

如何进行链接?框架代码是否将编译到应用程序中?这将如何影响包/二进制文件大小?

是的,框架代码将编译到应用程序中。对于包大小,由于大多数应用商店应用都有大量多媒体,因此差异不明显。因此,代码大小确实会发生变化;但是,仅会将应用使用的框架部分链接到应用中。最终结果是,使用 .NET Native 编译的二进制文件将与执行 NGEN 的二进制文件处在相同的大小范围中。我们仍将研究可进一步减少大小差异的策略。

使用 .NET Native 编译比使用 MSIL 编译慢。为什么?

常规应用开发使用 Visual Studio 中的标准 MSIL/JIT 开发体验。只有在将应用部署到设备才会调用 .NET Native 编译器,在大多数开发过程完成之后,重心将转移到应用的优化上。此时,编译时间与使用链接时间代码生成优化的 C++ 的差不多。

P/Invoke 有什么变化?是否会将它们优化为标准 DLL 调用?

即使对二进制文件进行本机编译,但我们保留了托管代码类型安全性(以及垃圾回收)和完整 C# 异常模型的好处。利用 .NET Native,我们还极大地优化了互操作路径 - 因此,尽管 P/Invoke 不会优化为标准 DLL 调用,但开销极低,以便执行 GC 同步和任何必需的封送。

有什么限制?此产品是否支持开放的泛型和反射?



相关评论