C#/F# 性能比较 [英] C# / F# Performance comparison

问题描述

网络上是否有任何 C#/F# 性能比较来显示新 F# 语言的正确使用?

Is there any C#/F# performance comparison available on web to show proper usage of new F# language?

推荐答案

自然 F# 代码(例如功能性/不可变)比自然(命令性/可变面向对象)C# 代码慢.但是，这种 F# 比通常的 C# 代码要短得多.显然，这是一种权衡.

Natural F# code (e.g. functional/immutable) is slower than natural (imperative/mutable object-oriented) C# code. However, this kind of F# is much shorter than usual C# code. Obviously, there is a trade-off.

另一方面，在大多数情况下，您可以实现与 C# 代码性能相同的 F# 代码性能.这通常需要以命令式或可变的面向对象风格进行编码，分析并消除瓶颈.您可以使用在 C# 中使用的相同工具:例如.Net 反射器和分析器.

On the other hand, you can, in most cases, achieve performance of F# code equal to performance of C# code. This will usually require coding in imperative or mutable object-oriented style, profile and remove bottlenecks. You use that same tools that you would otherwise use in C#: e.g. .Net reflector and a profiler.

话虽如此，还是有必要了解 F# 中的一些会降低性能的高效率构造.根据我的经验，我见过以下案例:

That having said, it pays to be aware of some high-productivity constructs in F# that decrease performance. In my experience I have seen the following cases:

• 引用(相对于类实例变量)，仅在执行数十亿次的代码中

• references (vs. class instance variables), only in code executed billions of times

F# 比较 (<=) 与 System.Collections.Generic.Comparer，例如在二分查找或排序中

F# comparison (<=) vs. System.Collections.Generic.Comparer, for example in binary search or sort

尾调用——仅在编译器或 .Net 运行时无法优化的某些情况下.如评论中所述，取决于 .Net 运行时.

tail calls -- only in certain cases that cannot be optimized by the compiler or .Net runtime. As noted in the comments, depends on the .Net runtime.

F# 序列比 LINQ 慢两倍.这是由于引用和使用F#库中的函数来实现seq<_>的翻译.这很容易修复，因为您可以将 Seq 模块替换为使用 Linq、PLinq 或 DryadLinq 的具有相同签名的模块.

F# sequences are twice slower than LINQ. This is due to references and the use of functions in F# library to implement translation of seq<_>. This is easily fixable, as you might replace the Seq module, by one with same signatures that uses Linq, PLinq or DryadLinq.

元组，F#元组是在堆上排序的类.在某些情况下，例如一个 int*int 元组，它可能需要使用结构体.

Tuples, F# tuple is a class sorted on the heap. In some case, e.g. a int*int tuple it might pay to use a struct.

分配，值得记住的是，闭包是一个类，用 new 操作符创建，它记住访问的变量.可能值得解除"闭包，或将其替换为显式将访问的变量作为参数的函数.

Allocations, it's worth remembering that a closure is a class, created with the new operator, which remembers the accessed variables. It might be worth to "lift" the closure out, or replaced it with a function that explicitly takes the accessed variables as arguments.

尝试使用内联来提高性能，尤其是对于通用代码.

Try using inline to improve performance, especially for generic code.

我的经验是先用 F# 编码，然后只优化重要的部分.在某些情况下，用 C# 编写慢函数可能比尝试调整 F# 更容易.但是，从程序员效率的角度来看，在 F# 中启动/原型化然后分析、反汇编和优化是有意义的.

My experience is to code in F# first and optimize only the parts that matter. In certain cases, it might be easier to write the slow functions in C# rather that to try to tweak F#. However, from programmer efficiency point of view makes sense to start/prototype in F# then profile, disassemble and optimize.

最重要的是，由于程序设计决策，您的 F# 代码最终可能比 C# 慢，但最终可以获得效率.

Bottom line is, your F# code might end-up slower than C# because of program design decisions, but ultimately efficiency can be obtained.

这篇关于C#/F# 性能比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！