dotnet fsi startup overhead surprisingly high · Issue #12636 · dotnet/fsharp · G...

Is your feature request related to a problem? Please describe.

Startup time for fsx files is quite high. It might not matter if you are planning to do a large computation, but for small scripts, it seems to be routinely a few seconds, even for an empty fsx file with just () as code. I ran some benchmarks against similar python programs for comparison on a few machines, [inspired by this comment] (https://twitter.com/vilinski/status/1485188447639851012)
For small operating system tasks, running a tiny F# script would incur significant overhead, and it's a small barrier to starting up a quick REPL session/

Some tests I tried

Hello world, windows, dotnet 6.0.101, git bash

$ cat hw.fsx
printfn "hello world"

$ time dotnet fsi hw.fsx
hello world

real    0m2.711s
user    0m0.000s
sys     0m0.031s

daz@DarrenHP MINGW64 /c/src/tmp
$ dotnet --version
6.0.101

For comparison, here is hello world python

$ time python hw.py
hello world

real    0m0.386s
user    0m0.000s
sys     0m0.031s

$ cat hw.py
print("hello world")
$ python --version
Python 3.9.2

It's not even about really running the F# code itself, similar tests get 1.8ish seconds for a completely empty .fsx file. Interesting, adding in just the expression () adds about another half second.

$ cat null.fsx
()

$ time dotnet fsi null.fsx

real    0m2.397s
user    0m0.000s
sys     0m0.030s

$ cat empty.fsx

$ time dotnet fsi empty.fsx

real    0m1.778s
user    0m0.000s
sys     0m0.031s

Again python seems to shrug off having nothing to do very quickly

$ cat null.py

$ time python null.py

real    0m0.162s
user    0m0.000s
sys     0m0.031s

Curiously, and this is hard ti time but if I run fsi without a script associated, and just hit ctrl-D really really quickly, I can be in and out of the reply in about a half-second (even with human reflexes), so there is something about an fsx file specifically which seems to slow things down. I guess that's good if you just want to play interactively

$ time dotnet fsi

Microsoft (R) F# Interactive version 12.0.0.0 for F# 6.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

>
real    0m0.603s
user    0m0.000s
sys     0m0.031s

For comparison, on a fairly high end linux AWS instance (m4.4xlarge, 16 vCPU, 64 GiB ram), with dotnet 6.0.101

time ~/.dotnet/dotnet fsi null.fsx

real    0m1.702s
user    0m1.588s
sys     0m0.131s

Describe the solution you'd like

It's totally a qualitative thing, but overhead for commencing execution of an fsx file should comparable to the startup file for the reply (let's say a half second but closer to the python times of 0.2 seconds would be ideal)

Describe alternatives you've considered

This doesn't matter if you are compiling code but for running scripts, especially lots of small scripts back to back, the two seconds would be problematic and making fewer smaller scripts or a different scripting system would be the solution.

Additional context

I did a little profiling with strace and strace -c on a linux machine. I'm not sure this is super informative really - the total reported time in system calls is just 0.035 seconds. I suspect the time is more in userland but I'd have to profile the whole startup to see that bit. Trace output attached. There does seem to be a large pause in the output from strace for a second or so in the middle just watching it interactively but I don't think it's necessarily making a system call at that time.

strace-output.txt
strace-c-output.txt