Open jaredponn opened 7 months ago
Okay, some final numbers
$ time nix flake lock
real 0m12.575s
user 0m12.342s
sys 0m0.264s
$ cat flake.lock | jq '.nodes | keys' | awk -e 'BEGIN { i = 0 } /nixpkgs/ { i++ } END {print i }'
375
If we want to get this to back to be the numbers in the original PR, we'll need to modify the plutus-ledger-api-rust since that's contributing a significant overhead e.g. the following patch
diff --git a/flake.nix b/flake.nix
index 792c091..5b02a10 100644
--- a/flake.nix
+++ b/flake.nix
@@ -39,10 +39,10 @@
};
# Rust runtime
- plutus-ledger-api-rust = {
- url = "github:mlabs-haskell/plutus-ledger-api-rust";
- inputs.nixpkgs.follows = "nixpkgs";
- };
+ # plutus-ledger-api-rust = {
+ # url = "github:mlabs-haskell/plutus-ledger-api-rust";
+ # inputs.nixpkgs.follows = "nixpkgs";
+ # };
};
outputs = inputs@{ flake-parts, ... }:
gives us the following
$ time nix flake lock
real 0m0.942s
user 0m0.852s
sys 0m0.066s
$ cat flake.lock | jq '.nodes | keys' | awk -e 'BEGIN { i = 0 } /nixpkgs/ { i++ } END {print i }'
117
(of course, we wouldn't want to just comment it out because we probably need it somewhere -- I'm fairly certain the problem is the cyclic reference from lambda-buffers to plutus-ledger-api-rust; and if we could remove the cyclic reference, we could make plutus-ledger-api-rust follow lambda-buffer's flake-lang to significantly reduce the flake.lock size.)
More putting
follows
everywhere.Before this PR:
EDIT: we don't have such nice performance anymore -- see below After this PR: