Back to Questions
1.8k
views5
comments
Compiler performance
f#compiler

I noticed that the F# compiler is quite a bit slower than the C# compiler.

Will the performance be improved in VS2010, or is it an inherent result of the OCaml baggage?

.

While I think the performance will improve some with the upcoming release (Don has recently coded some perf wins), I think it will never be as fast as the C# compiler, for a variety of reasons including:

The F# compiler is written in managed code; the C# compiler is written in C++.

The F# compiler does lots of type inference which can be computationally expensive; the C# compiler does little of this.

The F# compiler does lots of optimizations; the C# compiler does few.

By on 9/30/2009 5:14 PM ()

> The F# compiler does lots of optimizations; the C# compiler does few

Are these documented?

I'm especially interested in whether ideomatic and convenient F# constructs will be "free". For example:

match a, b with

| 1,2 -> ...

| 3,4 -> ...

| _,_ -> ...

So in the above case does (a,b) create temporary tuple-garbage and use structural comparison, or is it just compares/branches?

(Yes, can use reflector, but would be cool to have a list of compiled-away constructs.)

thanks

By on 9/30/2009 6:28 PM ()

Not to sound like a jerk, but why does it matter if the F# compiler is faster or slower than its C# equivalent? Shouldn't the only real speed question be: 'is it fast enough'? (The answer, of course, is yes.)

By on 10/1/2009 6:19 AM ()

Not to sound like a jerk, but why does it matter if the F# compiler is faster or slower than its C# equivalent? Shouldn't the only real speed question be: 'is it fast enough'? (The answer, of course, is yes.)

That answer is becoming "no", for several reasons:

1. It's taking longer and longer for the errors to disappear every time I finish typing or editing a bit of code. It's particularly frustrating in F# because the errors are often much harder to understand due to the fact that type inference causes errors far away from where the actual problem is.

2. Particularly for this version, the lack of IntelliSense means that I'm more likely to make mistakes -- and I need to wait more often to see if I'd made any.

3. One of the perks of F# is that it's otherwise a lot more conducive to an interactive workflow, and especially because code can't be changed on-the-fly yet, I tend to compile my code in the interactive window a lot more often -- and that starts becoming noticeably slow after only a few hundred lines of code.

By on 10/1/2009 1:34 PM ()

Ahh, okay. Thanks.

By on 9/30/2009 5:23 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper