Clever Geek Handbook

Can the F # compiler be accelerated?

Since F # 1.9.6.16 and Mono 2.4.2.3 I cannot build FOT after getting segmentation fault. fsi

barely usable (and sometimes crashing) and fsc

rather painfully slow. On windows, F # is not the fastest compiler. Is there anything that can help?

+2


source to share


3 answers


The best way to help this situation is with error files. If you have a specific project or environment that is slowing down significantly, I highly recommend that you file a bug. Real-world scenarios are often very instructive in tracking down performance problems in products.

F #, like the rest of the languages ​​in visual studio, handles client errors logged through the Microsoft connect website.



(EDIT: For your specific F # case, you can also email fsbugs@microsoft.com. )

+3


source


I just found a way to write F # scripts on Linux that don't rely on fsi

, but rather automatically recompile and therefore fast enough:

Considering /usr/local/bin/fsx

:

#!/bin/bash
src=$1
tgt=$src.exe
if [[ $src -nt $tgt ]]
then
    fsc $src -o $tgt >/dev/null && exec mono $tgt
else
    exec mono $tgt
fi


It is possible to write scripts that omit the shebang, relying on the default wrapper:

#light (*
    exec fsx $0
*)

printfn "Hello, world!"

On startup, the shell skips the first line, considering it a comment, and runs exec fsx $0

which compiles the script with fsc

if the executable is out of date, then runs it. For F #, a shell command is just a comment.

+4


source


In Mac OS X, the fsharpi

.

hello.fs:

#light (*
    exec fsharpi --exec $0 --quiet
*)

System.Console.WriteLine "Hello World"
+1


source






More articles:


All Articles