Fable tool slower than local build

[ncave]

I've noticed that the Fable dotnet tool is 3x slower than a local Fable build, for some reason. It's applicable to all tool 4.x releases.

See attached file for an example, it takes 3x longer to compile it with any 4.x Fable tool vs compiling it with a local Fable build.

FSComp.fs.gz

[alfonsogarciacaro]

By local Fable build you mean running dotnet build src/Fable.Cli?

I've tried putting your code in a single-file project and got the following times running dotnet fable --noCache

Fable 3.7.20: Fable compilation finished in (around) 4500ms Fable 4.1.0-beta-001: Fable compilation finished in (around) 5500ms

Obviously this needs profiling and better benchmarking but it seems the extra time comes exclusively from Fable and not from FCS. In part it's expected because we are doing more work. We can do some profiling to see if we (by we I mean I) have introduced some bottleneck, but my feeling is this is a worst-case scenario: it's a single big file (so parallelization doesn't help) with a single class (so TryFindMember takes longer). IIRC I did try to convert the members into a dictionary but this didn't help much because in general classes don't have many members, though we can give it a new try.

Things off the top of my head we can try to improve performance.

• Profiling to find bottlenecks (as commented above)
• Parallelizing at declaration level: I think at least we can do this for FableTransforms because the transformations in this step don't share a context.
• Streamlining the steps, so instead of waiting for the whole file to be compiled at each step (FSharp2Fable > FableTransforms > Fable2Babel > BabelPrinter), we move each declaration to the next step as soon as it's ready. A tricky thing was that we are compiling the imports at the end of Fable2Babel but they have to be printed at the beginning in BabelPrinter. However, now we are printing to a MemoryStream, so it shouldn't be a problem to "go back" and insert the imports on top even if they are calculated at the end.

[ncave]

@alfonsogarciacaro Sorry about not being clear enough, let me try again:

• It's not about Fable v3 vs v4 performance, it's about Fable tool v4 vs Fable CLI v4.
• By local Fable build I mean to build Fable CLI locally and run it in Release mode to compile the single-file project that you created with the attached file above. Also, run it for --lang=TypeScript.

Of course, if you cannot reproduce, it's entirely possible that there is something wrong on my machine. But for me all Fable tool versions are pretty consistently 3x slower than local Fable CLI (running on WSL).

Could it be that fable tool runs some arg by default that I don't run on my local CLI? Otherwise why would presumably the same exact code (latest tool vs latest CLI) run differently? I can't think of anything else, but I'll try on another machine to try to replicate.

[ncave]

Closing ~until it can be reproduced~, not an issue.

[alfonsogarciacaro]

So it's:

dotnet tool install fable --prerelease
dotnet fable --noCache

Vs:

dotnet run -c Release --project ../fable/src/Fable.Cli -- --noCache

Is that correct? I have tried both commands in Windows and WSL (Ubuntu 20.4) with dotnet 7, but I haven't noticed much of a difference in compiling time.

If you pass the same arguments to Fable there shouldn't be a difference between the tool from nuget and your local CLI. Make sure that you have disabled the cache (--noCache) and that you're not using watch mode which automatically selects Debug mode. You can also use --verbose option to make sure the same compiler args are being passed to FCS/Fable in each case.

[ncave]

Thanks @alfonsogarciacaro, yes, the problem was between the keyboard and the chair. I was not running them with the same arguments. The difference turned out to be the extra printing of F# AST that I was doing when running the tool. Without it they are indeed the same (of course they are). Thanks for looking into it, sorry about that.

[MangelMaxime]

I would have love if there was actually an easy to solve performance problem as we could have had Fable even faster 🙈