Compile time regression with PAB/TraceEmulator Effects.

[t1lde]

Area

[] Plutus Foundation Related to the GHC plugin, Haskell-to-Plutus compiler, on-chain code
[x] Plutus Application Framework Related to the Plutus application backend (PAB), emulator, Plutus libraries
[] Marlowe Related to Marlowe
[] Other Any other topic (Playgrounds, etc.)

Summary

We have a moderately sized project currently (~40 modules) and compile times seem to have gotten longer (~300s, not including any dependencies) as we have added more endpoints to the Contract monad effects row.

I think this is probably related to the previous regressions from the row-types library, but not from our end - inlining the results of the .\/ type family doesn't seem to help.

It seems to be taking most of the time compiling the tests modules (6 total), which make use of Plutus.Contract.Test and TraceEmulator in particular. A Main module which uses Simulator effects also seems to compile slowly.

This could be due to something that has been fixed in updates of dependency libraries, but we haven't been updating the dependencies in stack.yaml as frequently as the plutus version (the plutus sample stack.yaml doesn't seem to have been updated often, either).
Apologies if this has already been fixed since the plutus commit we're currently working with, I didn't see anything that looked as if it might be a fix. And it would take some code changes to update to the latest master commit.

Info

• Plutus Version
  4fd9551
• Build System
  stack, without --fast due to the PlutusTx plugin limitations
• stack.yaml.lock
  https://gist.github.com/t1lde/937b48a4a032d05eab6bd765b66b27d7
• Compilation time
  <build command> 309.54s user 17.98s system 115% cpu 4:42.51 total
• GHC Version
  ghc8103

[luigy]

I wonder if this is something that would benefit from target/row-types#77 ? curious how it goes if you end up trying an override locally

[t1lde]

I'll keep an eye on it if our compile time gets any worse, for now I've been able to improve things some with more aggressive use -O0 (tricky with the plugin in the mix)

[ghost]

Previous issues with row-types led to humongous memory usage and compilation errors if memory was not enough. There were fixes for some operators from row-types but the reason this time can be a different.

I think it might be useful to play with memory limitations with GHC flags ghc-options: -W +RTS -M1G -RTS changing memory limit. It's hard to tell where's the problem without a snippet or a reproducible case.

[t1lde]

I think it actually might be different from the memory-usage issue with row types.
Have also been noticing when compiling that plutus-use-cases is compiling slower.

[luigy]

@t1lde you should give a more recent master a try that includes #3342 . I'm seeing significant shorter reload times in the repl in my tests. Haven't measured building yet

[ghost]

Closing this issue as it should be fixed.

If it's not, please re-open.