F＃和C＃的CLR相同，那么为什么F＃比C＃快

Question

I am confused and would appreciate if you enlighten me. F# uses same CLR as C# and underlying code is identical then how can one suggest that a function runs faster when written in F# than C#? If I use only immutable variables in C# and performance needs to be as high as possible then why use F#?

Answer 1

underlying code is identical? Doubtful. In general, F# will be faster in some things and slower in others. The same is true of C#. Or even VB. Each language has its pluses. If there is an overall performance plus in most areas, it is in the compiler.

If I use only immutable variables in C# and performance needs to be as high as possible then why use F#? No reason to switch for performance alone, if in fact there is a real difference, unless perf is your problem. As far as why switch if you are only using features that are fine in C#, I would say "don't switch".

I like F#. There are some "problems" it solves much better than C#. But, even if I have a problem it solves better, I am not necessarily switching, as I have to consider the developers in the mix. Currently, I know of few in this organization that know anything about F#, so I would have to make a good business case to switch.

Ultimately, you have to look at the "business problem" and determine a path. You have to consider the "better" language as part of the mix, but you also have to examine core competency, etc.

Answer 2

1) If you write C# code and F# code which gets compiled to exactly the same IL (the CLR's intermediate language), then the code will exhibit the same performance characteristics. However, implementing the same algorithm in C# and F# does not guarantee that exactly the same IL will be generated, so real world performance may vary. I believe that in practice sometimes F# code will be faster but other times C# will be faster.

2) There are many reasons to choose an implementation language besides performance. For example, some people find F# to be more succinct, readable, and easier to reason about than C# for certain problem domains, which would be one reason to prefer it. For the vast majority of programs, a 5% or 10% difference in performance is going to be imperceptible to users, so if a language offers roughly comparable performance but superior productivity then it would make sense to use that language.

Answer 3

There was this question on stackoverflow some time ago, it may help you to figure out some reasons why F# could be faster. The performance gain depends very much on the application and the coding features you are using though.

Answer 4

You might be interested in the article Performance-Related Features in F# and C# . As for "why use F#" I can't speak for you, but for myself I use F# because I like it better.

Answer 5

There could be any number of reasons for code written in one language to be faster than code written in the other, even if they use the same runtime library. However, the .NET runtime library isn't the only runtime library involved. As I understand it, there is a rather large F# runtime library that does things that are F#-specific. The F# compiler knows about that library. The C# compiler doesn't. So the F# compiler can make calls to highly optimized runtime library code that the C# compiler doesn't have access to.

If they're both using the same set of runtime libraries, then I would expect the programs to be close to the same, but not exact. The individual compilers could generate more or less optimum code for particular constructs.

Answer 6

There is no reason to switch but I suggest components built to meet the best standards. F# enforces alot of standards, makes real time testing during development simple, and cures issues of mutability, circular dependency, as well as most type checking / null references. C# on the other hand has the majority of developers and tools and can be developed with a functional pattern in mind but not always correct. I'm a C# fan and almost always choose C# but I see many times when F# is what I need most to build cleaner robust code. I guess, I personally prefer to blend the two languages when I can but as mentioned it's more important to work with what your dev team can also maintain and review. In many situations, the dev team will be against it but in some they will be for it because they also want not only to make the code base as strong as possible but learn new things. Just don't waste too much time deciding the correct language, if you're certain F# is best, present it and see if you have a consensus to complete it that way. Keep your project separate, even if they are in the same solution, and use F# when it works best and C# when it works best. F# isn't that hard to learn, but to a purely imperative developer it might look ugly and confusing at first. Just explain it some and I think it gets the ball rolling. Times to consider F# would be in algorithms where you not only want performance but immediate testing of the results. This speeds up dev time and runtime, win win. Others might be models if the models consist of many immutable values. F# works in all areas but for me the UI side is done easier in C# as well as things like ViewModels where logic is slightly different but that's an opinion. You'll be surprised at the gains you get from a sweet combination of the two. Besides, functional programming is getting easier with linq, lambda, and newer C# syntax where C# basically looks functional so your pitch to use F# may not be as tough as it would years ago.
I didn't cover anything to the max but you get the idea...F# is powerful, use it when it works best and the same for C#. I started with VB.NET but wouldn't recommend it anymore simply because newer tech like .NET Core isn't supporting it. However, there is also a benefit to use it at times... Although be it far less than a benefit of F#. In that regard I just stick to the two primaries C#, F#.

Answer 7

The answer isn't the performance in speed or resources BC they are nearly the same. Some debated enhancements and cons... The reason for F# is development and deployment time. F# is more streamlined and eager to build with safer code. Less error prone and more exact without worry about simple things like loop counters and type checking, cross threading etc. Therefore it is not only easier and faster to write but far less buggy. You get more of what you really wanted without worrying about the petty things. This means less testing and more live deployment, more trusted code and more precise functions that don't carry unneeded overhead. Therefore the bottom line result is faster written code, optimized performance by nature, and equally as much trust with less error.