Current REPL perf (1.3.*)

[ncave]

@alfonsogarciacaro There are some good perf news and some not so good:

• REPL now works again, apart of a few minor warnings that don't seem to affect it.
• REPL perf has not changed much from Fable 1.2.0.
• REPL with netstandard2.0 assemblies works now too.
• but, REPL perf with netstandard2.0 assemblies is noticeably slower than with net45 assemblies (especially for larger files). Fixed in added PhysicalHash #1300, see below.

Some perf data:

• Fable REPL - net45 assemblies (best times):

checker create time:  2552 ms
tailcalls: FCS time:    23 ms, Fable time:  37 ms
   sudoku: FCS time:   256 ms, Fable time: 364 ms
raytracer: FCS time:  1102 ms, Fable time: 826 ms

• Fable REPL - netstandard2.0 assemblies (best times):

checker create time:  8335 ms
tailcalls: FCS time:    25 ms, Fable time:  37 ms
   sudoku: FCS time:  1175 ms, Fable time: 335 ms
raytracer: FCS time: 14725 ms, Fable time: 931 ms

So it starts the same for smaller files, but scales very differently with the size of the file being parsed.
Fixed in #1300, see below.

[alfonsogarciacaro]

Hmm, that's bad news. Yeah, maybe the JS runtime doesn't handle multiple files that well. Actually, they are byte arrays in memory so maybe they cause overhead in garbage collection somehow 🤔

[ncave]

This PR fixed the startup (checker create) times for netstandard2.0, but the rest is still not good, there is a bottleneck somewhere that needs to be profiled out.

[ncave]

Some performance improvements in #1300.

[ncave]

• Latest Fable REPL bench times - netstandard2.0 assemblies (best times):

checker create time:  3327 ms
tailcalls: FCS time:    35 ms, Fable time:  38 ms
   sudoku: FCS time:   253 ms, Fable time: 285 ms
raytracer: FCS time:  1033 ms, Fable time: 704 ms

The checker create time went up almost a second, possibly due to now also loading optimization data during creation.

Still roughly about 10x slower than the (highly optimized) dotnet release version, so further profiling/optimization is definitely something to look into. Any ideas are welcome!

[alfonsogarciacaro]

Great! Yes, I need to work more on #1266 so we can apply the optimizations from the F# compiler, that looks very promising. BTW, I also started work on the optimize-pass branch to remove most of the hacky optimizations applied directly to F# AST and add an optimize pass directly of Fable AST after replacements, mainly for beta-reduction. This may interest @forki as well.

Some day I also need to sit down with an expert in JS engines to see if the F# types (particularly DUs) representation can be improved. @cartermp Do you happen to know someone in the Chakra team that could help us with that?

[cartermp]

Let me see!

[cartermp]

Hmmm. Actually, can you ping me on this sometime in January? Half of the company is out of office and on vacation, so I doubt someone could provide any advice right now.

[alfonsogarciacaro]

Move discussion about optimization to #1266